MongoDB: Рекомендации по оптимальной архитектуре и безопасности

Question

Предполагая, что мы создаем веб-страницу с определенной страницей профиля для пользователей, каждый пользователь должен быть идентифицирован с помощью уникального идентификатора. В MongoDB это скорее всего столбец _id документа. При обращении ссылку на профиль пользователей, я не чувствую себя комфортно подвергая фактической идентификатор базы данных в веб-ссылку, например

https://www.foopage.com/userprofile/5612afeedd2387aeeebbdd211100ccdd

Вместо этого, я хотел бы представить более короткий идентификатор, а также может можно увидеть на YouTube, где каждое видео имеет уникальный 10-значный буквенно-цифровой код. Мой вопрос сейчас:

1) С точки зрения безопасности: стоит ли скрывать фактический идентификатор документа от общественности или он фактически не повышает безопасность системы?

2) Я ожидаю недостатков в производительности, используя свой собственный идентификатор, поскольку собственный _ID MongoDB, скорее всего, индексируется и «оптимизирован», тогда как мой идентификатор всегда требует какого-то сопоставления данных или дополнительной индексации. Каков ваш опыт? Есть ли задокументированная разница в использовании собственного индекса и созданного вручную для MongoDB?

Answer 1

1) С точки зрения безопасности: стоит ли скрывать фактический идентификатор документа от общественности или он фактически не повышает безопасность системы?

Обычно злоумышленник не должен иметь какую-либо выгоду от зная ObjectID годов. Это означает, что если вы не создадите уязвимость в вашем приложении, которая может быть использована, зная идентификатор.

Другая вещь, о которой вы должны знать, это то, что ObjectID не являются полностью случайными. Они также просачивают идентификатор машины, идентификатор процесса процесса, который сгенерировал его, а также дату и время создания идентификатора. См. the documentation для получения дополнительной информации. Ни одна из этих данных не является критически важной для безопасности (хотя время создания - это то, что вы, возможно, не захотите выявить в случаях), но может быть полезной информацией для злоумышленника, пытающегося использовать некоторые другие уязвимости вашей системы.

Это означает, что скрытие объектовID как часть стратегии защиты по глубине может быть полезно, но это только безопасность через неясность. Не ожидайте, что ObjectIDs будут секретными.

2) Я ожидаю недостатки производительности, используя свой собственный идентификатор, как родную _ID из MongoDB, скорее всего, индексируется и «оптимизирована», в то время как мой идентификатор всегда требует какого-то отображения данных или дополнительной индексация.

Знаете ли вы, что ваши значения _id не обязательно должны быть идентификаторами ObjectID? Вы можете использовать любое значение любого типа, который вы хотите, если он уникален на уровне сбора. Поэтому, если ваши данные уже имеют уникальный идентификатор, вы можете использовать это как _id и сохранять несколько байтов и индекс. Для этого просто установите поле _id документа на нужное значение, прежде чем вставлять его в базу данных.

Если вы хотите сохранить шаблон _id:ObjectID, вы можете просто создать уникальный индекс в поле вашего идентификатора приложения. Теперь у вас есть как минимум два индекса, которые обновляются на каждой вставке, но это не должно быть очень тяжелым, если ваше приложение не очень тяжело писать (что было бы необычно в контексте веб-приложения).

К сожалению, URL-адрес example.com/userprofile/5612afeedd2387aeeebbdd211100ccdd не очень дружественный поисковой системе. Было бы лучше иметь URL-адреса, такие как example.com/userprofile/IgorP. Они более читабельны как для поисковых систем, так и для пользователей.