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