При создании нашего сервиса в производственной среде или, возможно, в среде разработки с несколькими пользователями, первое, что мы должны сделать, это создать схему безопасности, которая позволяет нам предотвратить доступ людей к нашим базам данных каким-либо образом. неверен.
Главная особенность MongoDB заключается в том, что при установке экземпляра, который он запускает без создания какого-либо типа меры аутентификации, это облегчает начало разработки, но наступает момент, когда мы должны защитить нашу инфраструктуру.
Еще один важный момент, связанный с безопасностью и резервным копированием наших данных, - это когда нам нужно сделать резервную копию на определенный момент, но мы не хотим перемещать данные, поскольку таким образом мы гарантируем целостность нашей базы данных и коллекции документов. В этом отношении в MongoDB также есть инструмент, который позволяет нам временно блокировать его, чтобы гарантировать, что то, что мы копируем, является подходящим.
требования
Требования, которые нам нужны в этом случае, очень просты, нам просто нужно установить и запустить экземпляр MongoDB в нашей системе, нам также потребуется доступ к службе через консоль. Это руководство было разработано в Windows, поэтому возможно, что некоторые команды изменятся в других операционных системах, но все связано с тем, что делается вне консоли MongoDB, и с тем, как мы выражаем маршруты.
Безопасность и аутентификация
Установка параметров аутентификации пользователя не является жизненно важной для работы MongoDB на производстве, поскольку мы можем установить службу так, чтобы оборудование, на котором она работает, имело фильтр подключения, поэтому, если мы попытаемся получить доступ к указанному оборудованию вне сеть не доступна.
Этот упрощенный подход к безопасности очень эффективен, но только для проектов, в которых служба не используется совместно с другими командами, поскольку, если у нас работают разные команды разработчиков на одном сервере, нам нужно что-то еще. Здесь начинается аутентификация, поэтому мы позаботимся о том, чтобы запросить пользователя и пароль для каждой коллекции, если захотим, чтобы у нас была возможность надлежащим образом разделить различные экземпляры для каждой команды.
Обе меры безопасности не являются исключительными, и если мы хотим использовать их одновременно, мы создаем гораздо более безопасный сервис для нашей среды, будь то производство, подготовка к производству или разработка с использованием нескольких устройств.
Базовая аутентификация
Аутентификация в ее самой простой форме достигается с помощью команды createUser, которая должна выполняться, когда мы выбрали базу данных администратора , где должны быть наши пользователи.
Важно отметить, что, начиная с версии 2.6 MongoDB, использовался метод createUser, в прошлом все было разрешено методом addUser, однако это изменение было сделано для большей универсальности при внесении изменений.
Давайте посмотрим, как мы можем установить пользователя-администратора, а затем пользователя, который может только читать тест базы данных.
Структура документа, который получает метод createUser, выглядит следующим образом:
{"Пользователь": "имя пользователя", "pwd": "пароль", "роли": [{"role": "", "db": ""}, ]} Как мы уже отмечали, мы должны установить имя и пароль для пользователя, которого мы создаем, но в дополнение к этому мы должны также создать роли, которые представляют собой структуру разрешений, которая позволит нам определять полномочия, которые мы даем пользователю. В следующем примере мы создадим пользователя-администратора, который имеет доступ ко всем базам данных и может управлять службой, для этого мы будем использовать роли :
- clusterAdmin
- readAnyDatabase
- ReadWrite
С этими тремя параметрами мы уже можем управлять нашим первым пользователем. Давайте посмотрим, как это выглядит на консоли:
После этого мы уже успешно создали пользователя-администратора, теперь мы должны правильно запомнить имя пользователя и пароль, потому что следующий шаг, который мы сделаем, - это включите защиту, для этого мы должны запустить службу с параметром –auth .
При перезапуске сервиса мы можем разместить нашего вновь созданного пользователя-администратора и протестировать его, мы создадим пользователя, который может только читать базу данных . Давайте посмотрим, как мы перезапускаем сервис в следующих шагах.
Мы просто должны сначала остановить его, например, в Windows мы позиционируем себя на консоли, на которой он запущен, и нажимаем клавиши CTRL + C. Затем мы снова запускаем наш сервис, но в конце мы передаем параметр auth, как мы видим в следующей консоли:
Как только это будет сделано, мы вернемся к консоли управления MongoDB, но в этом случае, если мы собираемся использовать нашего вновь созданного пользователя:
mongo.exe --username = root --password = 123456 adminС этой предыдущей строкой мы можем получить доступ к нашему сервису безопасным способом, это можно проверить на следующем изображении:
Важно помнить, что мы должны использовать более безопасный пароль, чем «123456», в этом примере он размещен только демонстративно, однако для производственной среды он не подходит.
Поскольку мы проверили, как получить доступ с аутентификацией, мы создадим пользователя, который может читать только в тесте базы данных, для этого мы повторим создание пользователя, но мы определим роль:
считываниеТаким образом, мы ограничим возможности пользователя не писать в коллекции. Давайте посмотрим ответ в нашей консоли: $config[ads_text5] not found
Теперь при попытке написать документ мы получим ошибку:
Затем мы увидели, как мы уже обеспечили надлежащую защиту наших пользователей, ясно, что эта работа по администрированию пользователей немного сложна, но как только мы это сделаем, мы можем быть уверены, что у нас не будет несанкционированного доступа к базам данных. Мы защищаем.
Резервное копирование с блокировкой данных
Одним из наиболее сложных действий, которое необходимо обеспечить при создании резервной копии, является то, что мы должны гарантировать целостность данных, это приводит нас к дилемме, определяет время, когда работает меньше пользователей, и создает резервную копию, или делает это независимо от данных.
fsync и lock$config[ads_text5] not found
Этого не должно быть, конечно, создание резервной копии в то время, когда мы знаем, что всегда рекомендуется наименьшее количество пользователей, так как мы избегаем проблем с приложениями, гарантируя, что данные всегда возможны, если мы используем то, что в MongoDB мы знаем как fsync и заблокировать .
С помощью этих двух параметров мы можем заставить нашу базу данных отклонять записи, и в этот момент мы можем делать резервные копии правильно.
Чтобы создать этот блок, мы должны запустить следующую команду в нашей базе данных:
db.runCommand ({"fsync": "1", "lock": "1"}); Благодаря этому наша база данных будет эффективно заблокирована от записи: 
Как мы видим, это довольно просто и эффективно, теперь, если мы хотим разбить блок, просто запустите команду еще раз:
db.fsyncUnlock ();С этим последним у нас будет наша База данных с возможностью получать записи:
Резервное копирование с ведомой машины
Несмотря на то, что вышеприведенное представляет большую гибкость и дает нам гораздо большую защиту от повреждения данных и способствует целостности, на самом деле это не та практика, которую мы должны применять в реальных производственных средах.
Идеальным является создание среды с репликацией, где мы можем получить доступ к копии данных и, таким образом, иметь возможность манипулировать любым из вариантов, которые у нас есть необходимые резервные копии. Находясь в реплике производственной базы данных, мы можем заблокировать ее или отключить и сделать резервную копию, чтобы пользователь никогда не столкнулся с ошибкой приложения, поскольку он не может записать запись.
Что касается резервных копий, дело обстоит сложнее, так как рекомендуется использовать серверные реплики, однако из-за способа, которым была задумана MongoDB, этот тип структур « ведущий-ведомый» очень легко реализовать, поэтому понятно Концепция является наиболее сложной, но ее применение чрезвычайно удобно для администратора баз данных .
На этом мы заканчиваем этот урок, так как мы видим, что администрирование MongoDB довольно продвинуто. Если у нас структура среднего размера, мы, возможно, уже подумали о проблеме безопасности пользователей, хотя создание пользователей не сложно, Если это хорошо, чтобы сесть, чтобы определить хорошую структуру для создания этого типа разрешения.
СТАТЬИ