Безопасность MongoDB Oplog
Мы используем набор копии MongoDB для совместного использования сессий и других (потенциально чувствительных) данных в веб-ферме.
Все данные, которые мы храним, используют индексы TTL для истечения документов после относительно короткого промежутка времени (скажите час), частично из соображений безопасности.
Однако мне пришло в голову, что, даже если данные удалены из набора MongoDB, oplog, используемый для репликации, будет все еще содержать все созданные документы (и затем удаленный); все данные, которые истекли, могут затем быть легко считаны с oplog.
В зависимости от размера, выделенного oplog, данные в нем могут быть довольно старыми.
Мой вопрос, что такое лучшая практика здесь? Есть ли что-нибудь, что мы можем сделать, кроме сильно уменьшают oplog размер, чтобы препятствовать тому, чтобы старые данные были доступны?
Конфиденциальные данные в журналах совпадают с конфиденциальными данными в любом месте. В зависимости от критичности, которую вы захотите -
разрешить доступ к данным только тем, у кого есть разрешение на просмотр (обычно это делается через роли или членство в группах).
если данные содержат какие-либо регулируемые или связанные с внешними проблемами сведения. в нем (PCI, HIPAA и т. д.) вы должны относиться к нему соответствующим образом и выполнять танец соответствия
, включив ведение журнала и мониторинг (как в сети, так и на хосте) на 11 (или что угодно)
, особенно. доступ к данным журнала и аудита и попытки
хранить журналы только столько времени, сколько необходимо
зашифровать, когда они не используются активно, если возможно
не разбрасывать их, объединить и защитить
, если они возрастут до определенного уровня беспокойства вы можете защитить сервер mongodb и рассматривать его как критическую систему (взлом безопасности: если вы имеете дело с данными PCI или другими типами данных, связанных с соответствием, вы можете притвориться, что у него есть эти данные, и операторы будут обращаться с ними тем же стандарты / политики / и т.д., которые вы применяете к ним, а не придумываете новый способ справиться со всем этим)
В случае mongo вы можете -
отправить его (в зашифрованном виде!) на центральный сервер журналов, в идеале с тегами как чувствительные или с более высоким уровнем серьезности
, либо не храните журналы локально, либо, если необходимо для отладки / чего-то еще, поверните их в забвение (например, выбросьте) по прошествии кратчайшего времени (день, неделя, 30 дней, независимо)
, если они существуют локально, убедитесь, что они принадлежат пользователю root / priv'd и в режиме 0400 (или как там ks для вашей ОС)
, если вы действительно параноик, вы можете использовать что-то вроде auditd (8), чтобы увидеть, когда кто-то пытается получить доступ к журналам (и снова, отправляя журналы auditd на центральный сервер журналов!)
если вы действительно параноик, вы захотите использовать зашифрованное хранилище везде, где хранятся журналы, чтобы их нельзя было погасить при удалении записи с диска
некоторые данные могут потребовать длительного хранения из соображений соответствия, поэтому убедитесь, что вы ничего не уничтожаете преждевременно
доступ к центральному серверу журналов должен иметь те же ограничения, что и на локальном сервере, потому что ... data
Ничего особенного, то же самое, то же старина, только ничего не упускай, прибивай все, ограничивай доступ и отслеживай все, что движется.