Архитектура API - обфускация/сопоставление/шифрование идентификаторов

Я разрабатываю RESTful API для своей компании, но у нескольких людей есть некоторые проблемы с раскрытием идентификаторов объектов, что я определенно вижу как проблему с защитой наших данных.

Мои данные ограничены, то есть вы не можете видеть данные, которые вам не принадлежат.

Я использую веб-API и EF6. Что вы сделали по этому вопросу? это вообще проблема (почему/почему бы и нет)?

Если это проблема;

  • Я шифрую или иным образом запутываю идентификатор?
  • Должен ли я внутренне сопоставляться с разными идентификаторами? - любые хорошие рамки для этого?
  • Должен ли я добавить столбец во все свои таблицы с uuid и вместо этого выставить его?

Что считается «хорошей практикой» или «безопасностью» в этом случае?

Редактирование этого ответа кажется хорошим решением, но мне все же хотелось бы узнать, что считается хорошим/плохим/отличным и, возможно, другие решения "проблемы"

Не проблема в соответствии с этим, я понимаю, почему это не должно быть проблемой, пока

  1. Данные защищены

c# entity-framework asp.net-web-api restful-architecture
person VisualBean    schedule 04.09.2015    source источник
comment
Если вы блокируете данные с помощью токенов доступа или чего-то подобного, какое значение имеют очевидные и видимые идентификаторы?   -  person Kirk Woll    schedule 04.09.2015
comment
Должен ли я скрывать первичные ключи (идентификаторы) базы данных во внешнем интерфейсе приложения?, Открытие идентификаторов базы данных - угроза безопасности?, Разоблачение внутренних идентификаторов БД является плохой практикой в URL?, Является ли раскрытие идентификатора автоинкремента базы данных плохой практикой?, ...   -  person CodeCaster    schedule 04.09.2015
comment
... Является ли скрытие/запутывание общедоступных идентификаторов баз данных действительно «лучшей практикой»?, Почему бы не предоставить первичный ключ.   -  person CodeCaster    schedule 04.09.2015

Ответы (1)


arrow_upward
0
arrow_downward

"Зашифровывать или иным образом запутывать идентификаторы?"

Если вам приходится это делать, возможно, вам не следует их возвращать.

"Должен ли я внутренне сопоставляться с разными идентификаторами? Есть ли для этого хорошие фреймворки?"

Похоже, что это сильно усложнит ваше приложение.

"Добавить ли столбец во все мои таблицы с идентификатором uuid и предоставить его вместо этого?"

При раскрытии идентификатора следует помнить, есть ли у вас определенное разрешение на просмотр что-то в конечной точке: /api/user/1 что должно помешать вам «пройтись» по URL-адресу и изменить его на /api/user/2 для просмотра чужих данных. Одна вещь, которую вы можете сделать, это использовать Guids в качестве идентификатора, чтобы предотвратить переход по URL-адресу, но в целом, если вам не нужно возвращать идентификатор, не делайте этого. Если вам нужно вернуть какие-либо конфиденциальные данные, то они ВСЕГДА должны быть через SSL.

person Stephen Brickner    schedule 04.09.2015
comment
Я использую базовую аутентификацию поверх https с ограниченными данными, поэтому вы не можете получить данные, которые принадлежат вам. - person VisualBean; 04.09.2015
comment
По крайней мере, если дырок нет :) - person VisualBean; 04.09.2015