Чому б не відкрити первинний ключ

В моїй освіті мені сказали, що це недосконала ідея викрити користувачеві фактичні первинні ключі (не тільки ключі DB, але й усі первинні аксесуари).

Я завжди вважав це проблемою безпеки (тому що зловмисник може намагатися читати речі не свої).

Тепер я маю перевірити, чи має право користувач все-таки отримати доступ, тож чи є інша причина цього?

Крім того, оскільки моїм користувачам доводиться отримувати доступ до даних, мені потрібно буде мати відкритий ключ для зовнішнього світу десь посередині. Тепер цей відкритий ключ має ті самі проблеми, що і первинний ключ, чи не так?

З'явився запит прикладу того, чому це робити все-таки, ось ось один. Майте на увазі, що питання стосується самого принципу не лише, якщо він застосовується в цьому прикладі. Відповіді, що стосуються інших ситуацій, явно вітаються.

Додаток (Web, Mobile), який здійснює діяльність, має декілька інтерфейсів користувача та принаймні один автоматизований API для міжсистемної комунікації (наприклад, бухгалтерія хоче знати, скільки стягувати плату з клієнта на основі зробленого). У додатку є кілька клієнтів, тому розділення їх даних (логічно, що дані зберігаються в одній БД) є обов'язковою системою. Кожен запит перевірятиметься на дійсність незалежно від того.

Діяльність дуже тонка, зерниста, тому вона знаходиться разом у якомусь контейнерному об'єкті, і називаємо це "Завдання".

Три випадки використання:

1. Користувач A хоче надіслати Користувача B на якесь завдання, щоб він надсилав йому посилання (HTTP), щоб виконати там деяку діяльність.
2. Користувач B повинен вийти за межі будівлі, щоб він відкрив Завдання на своєму мобільному пристрої.
3. Бухгалтерський облік хоче стягувати плату з клієнта за завдання, але використовує систему обліку третьої сторони, яка автоматично завантажує завдання / діяльність деяким кодом, який посилається на REST - API програми

Кожен із випадків використання вимагає (або стає простішим, якщо) агента мати якийсь адресаційний ідентифікатор для завдання та діяльності.

Крім того, оскільки моїм користувачам доводиться отримувати доступ до даних, мені потрібно буде мати відкритий ключ для зовнішнього світу десь посередині.

Саме так. Візьміть HTTP без громадянства, який інакше не знатиме, про який ресурс він повинен запитувати: він відкриває ідентифікатор вашого питання 218306в URL. Можливо, вам насправді цікаво, чи може виявлений виявлений ідентифікатор передбачуваний ?

Єдині місця, де я чув негативну відповідь на це, використовували обґрунтування: "Але вони можуть змінити ідентифікатор в URL-адресі!" . Тож вони використовували GUID замість належної авторизації.

Я можу уявити одну ситуацію, коли ви не хочете, щоб ваші ідентифікатори були передбачуваними: збирання ресурсів. Якщо у вас є веб-сайт, на якому публічно розміщуються певні ресурси, іншим може бути цікаво, і ви розміщуєте їх, як, /images/n.jpgабо /videos/n.mp4де nпросто збільшується кількість, кожен, хто шукає трафік на ваш веб-сайт і з нього, може отримати всі ваші ресурси.

Отже, щоб безпосередньо відповісти на ваше запитання: ні, це непогано безпосередньо "викрити" ідентифікатори, які мають лише значення для вашої програми, зазвичай для її роботи потрібно навіть успішно працювати.

Не слід виставляти його, оскільки люди, які бачать його, почнуть використовувати його як свій номер рахунку, який НЕ є. Наприклад, для мого банківського рахунку я знаю, що таке номер мого рахунку. Я запам’ятав це, я використовую його по телефону з обслуговуванням клієнтів, я використовую його при заповненні форм для інших банків для здійснення переказів, для юридичних документів, для моєї послуги автоматичної оплати тощо тощо. Я не хочу це змінити. Первинний ключ (для мого облікового запису) з іншого боку, я не знаю і ніколи не бачу.
Система, що зберігає її, змінюється протягом багатьох років від однієї системи до іншої, через злиття банків, оновлення та заміну системи тощо
. Первинні ключі можуть змінюватися через деякі з цих перетворень, тому, якщо його ніколи не викривали, не записували чи не пам'ятали будь-яким постійним користувачем, який "
Ключі без ділового значення часто називають сурогатними ключами і часто (але не завжди) використовуються як первинні ключі.

btw, це навіть відбувається внутрішньо, коли люди будують інтерфейси та програми, які неправильно використовують та відкривають первинні ключі та роблять їх частиною таких систем замість них, роблячи одне - однозначно визначаючи внутрішньо запис бази даних. Я фактично дізнався вище, через 6-річний термін підтримки системи зберігання даних у лікарні.

Тому що первинні ключі - це деталь реалізації.

Якщо ви мігруєте бази даних, ваші первинні ключі можуть змінитися через порядок вставки, видалення старих записів ... через кілька різних причин. Якщо ви мігруєте платформи баз даних, можливо, у вас більше немає фактичного первинного ключа. Викриття ПК над шаром доступу до даних - це непрохідна абстракція, з якою пов'язані всі проблеми зв'язку.

Це комбінована відповідь інших (ака. Те, що я дізнався). Якщо ви хочете подати заявку на цю заяву, вам слід принаймні відмітити один з інших, як вони виконали фактичну роботу. Якщо вас більше цікавить, прочитайте натомість інші відповіді.

Ви не повинні викривати первинний ключ баз даних, а замість цього використовувати сурогатний ключ

1. Якщо ви хочете, щоб ваші користувачі могли запам'ятати (принаймні трохи) або розпізнати ідентифікатор запису. ( Відповідь Graystone28s )
2. Якщо ви хочете планувати заздалегідь і вважаєте, що ви можете змінити системи (База даних чи іншим чином), які, ймовірно, змінять ПК. ( Відповідь Теластіна )
3. Якщо ви хочете переконатися, що ваші користувачі мають послідовний спосіб доступу до даних, які не змінюються, навіть якщо ваша компанія змінює право власності і ці дані мігруються в іншу систему взагалі. ( Відповідь Майкла Дюранта )
4. Якщо ваш ПК передбачуваний (як послідовність), ваша система може зазнати проблем зі збиранням ресурсів. ( Відповідь CodeCasters ) Це застосовується лише в тому випадку, якщо у вашій системі є інформація, яку варто збирати і яка доступна будь-яким чи принаймні тим, хто має інтерес до збирання.

Примітка: Ваш створений ключ повинен бути (свого роду) зрозумілим для людини (відповідь Sqlvogels ).

Якщо у вашій системі немає потреби від 1. до 4., немає підстав не використовувати бази даних ПК як свій загальнодоступний ідентифікатор (кілька відповідей). Також безпека тут не є проблемою (кілька відповідей).

Однією з причин я виявив, що в повному обсязі я бачив, як кінцеві користувачі просять, щоб їх ідентифікатор щось означав (наприклад, префікс або показник року, коли він був створений). Змінити ПК важко, але сурогат набагато простіше.

Ваш первинний ключ, ймовірно, буде те, на що ви хочете, щоб ваша база даних індексувалась з міркувань продуктивності, і ви можете вчасно з технічних причин змінити її, наприклад, з числа на настанову ... ви просто не знаєте, які причини нові технології чи знання може направити вас вниз. Ваш ПК - це ваші технічні дані, відкритий ключ - для споживання кінцевими користувачами.

Для більшості додатків дуже важливо, щоб ви не виставляли ключі користувачам. Для ефективного використання інформаційної системи користувачам цієї системи, як правило, потрібен спосіб ідентифікувати інформацію всередині неї та пов’язати цю інформацію з чимось у світі поза базою даних. У реляційних умовах бази даних ці ідентифікатори є ключами.

Один добре використаний шаблон дизайну полягає у створенні додаткового, чисто "технічного" ключа для таблиць баз даних як засобу абстрагування. Наприклад, щоб забезпечити стабільний (відносно незмінний) ключ, коли якийсь альтернативний ключ може змінюватися. Такі технічні ключі зазвичай не піддаються кінцевим користувачам, оскільки це підриває передбачувану абстракцію від вимог користувачів. Це не має нічого спільного з безпекою.

Проблема / непорозуміння, що маються на увазі у вашому питанні, пов'язані з невідповідним використанням терміна первинний ключ. Первинний ключ - це лише один з декількох ключів "кандидат" (кілька можливих ідентифікаторів у таблиці бази даних). Первинний ключ не обов'язково вимагає будь-якого принципово іншого властивості для будь-якого іншого ключа, тому твердження та принципи дизайну, які застосовуються спеціально до первинних ключів, а не до інших ключів, завжди підозрювані та часто помиляються.

Зважаючи на те, що зазвичай потрібно виставити ключ своєму користувачеві, яким він повинен бути? Спробуйте зробити свої ключі Знайомими, простими та стабільними. Ознайомлення та простота роблять ключі зручними для читання та запам'ятовування та допоможуть уникнути помилок введення даних. Стабільність означає ключові зміни нечасто, що також допомагає уникнути можливості неправильної ідентифікації.

Це з коментаря до відповіді Greystone28 від CodeCaster. Це приклад того, що ви говорите:

Я виставляю InvoiceNumber, який має значення для клієнта і його змінює, але я також розкриваю InvoiceID, який мій код використовує для унікальної ідентифікації рахунку. Вам не потрібно (а частіше не хочеться), щоб ключ користувача був ключем зберігання. Це питання стосується останнього.

Якій цілі у вашій програмі слугує показ відображення InvoiceID?

Експонуючи, я припускаю, що ви маєте на увазі, що користувач може його бачити. Викрийте його лише у тому випадку, якщо користувачеві потрібно його використовувати ваш додаток. Це може бути використане технічною підтримкою або деякими адміністративними речами. Я працював з кількома програмами, які роблять це. Це полегшує надання підтримки, коли я знаю конкретний запис.

Це цілком нормально, коли суб'єкти мають унікальний ідентифікатор, який піддається зовнішньому світу. Для деяких об'єктів можливо знайти ідентифікатор, який насправді має значення (наприклад, номер рахунку-фактури), але для інших такого ідентифікатора не існує, тому його потрібно генерувати.

Для послідовності та читабельності я вважаю гарною практикою для всіх організацій системи використовувати для свого ідентифікатора точно такий же тип та ім’я. Зазвичай цей ідентифікатор буде виставлений ( <type> getId()) у деякому абстрактному базовому класі.

З цієї ж причини кожна служба в системі (наприклад, служба виставлення рахунків-фактур) повинна надавати однакові методи доступу до об'єктів за їх ідентифікатором. Зазвичай цей метод ( findById(<type> id)) успадковується від загального інтерфейсу обслуговування або базового класу.

Цей ідентифікатор не повинен бути первинним ключем сутності, але він може бути одним. Єдине, що потрібно забезпечити, це те, що стратегія генерації ключів створює досить унікальні ідентифікатори (не потрібні універсально унікальні, але принаймні в межах системи).

Якщо пізніше система буде переміщена (велика, якщо на мій досвід), до іншої бази даних, тоді для створення ідентифікаторів не проблема використовувати іншу стратегію (не засновану на первинних ключах), поки стратегія сумісна з оригінальною.

Первинний ключ є саме так, як ручка до кортежу (запис, рядок), до якого ви намагаєтесь отримати доступ як розробник. Він також використовується в референтній цілісності (обмеження іноземних ключів), і, можливо, він також має один або кілька випадків використання.

По суті, немає нічого поганого в тому, щоб відкрити його користувачам, або навіть хакерам. Тому що я не знаю про атаку, яка, наприклад, використовує первинний ключ.

Але в безпеці у нас є багато принципів (які ми приймаємо і не схвалюємо), і нам потрібно їх дотримуватися:

1. Принцип пільги на оренду
2. Безпека через незрозумілість

І деякі інші принципи. Що вони говорять по суті, це те, що:

Якщо вам не потрібно виставляти свої дані, навіщо вам взагалі?