Одним из решений может стать использование для шифровки и расшифровки данных отдельного безопасного устройства. Еще одно решение — применение отдельного хранилища ключей, которым ваш сервис может воспользоваться, когда ему понадобится ключ. Важнейшей операцией может стать управление жизненным циклом ключей (и доступ к их изменению), и справиться с этой операцией за вас могут соответствующие системы.
В некоторые системы управления базами данных даже включена встроенная поддержка шифрования, например Transparent Data Encryption в SQL Server, которая нацелена на выполнение данных функций незаметно для пользователей. Даже если выбранная вами база данных способна на подобные действия, разберитесь, как происходит обработка ключей, и выясните, ослабевает ли в результате этого угроза, от которой вы стараетесь защититься.
Еще раз хочу напомнить, что это дело непростое. Не пытайтесь реализовать собственный вариант и хорошенько изучите доступные средства!
Установка на шифрование абсолютно всех данных может в каком-то смысле упростить ситуацию. Не нужно будет гадать, что стоит, а что не стоит защищать. Но вам все же придется думать о том, какие данные следует помещать в файлы журналов, чтобы проще было разбираться с проблемами. К тому же вычислительные издержки от шифрования всех данных могут стать весьма обременительными, что в результате выльется в необходимость использования более мощного оборудования. Все еще больше усложнится, когда частью ваших схем разбиения функциональных возможностей на более мелкие части станет применение миграций баз данных. В зависимости от характера вносимых изменений могут потребоваться расшифровка данных, их миграция и повторная шифровка.
Разбив вашу систему на большее количество узкоспециализированных сервисов, можно было бы определить единое хранилище данных, которое могло бы быть зашифровано целиком, но сомнительно, что из этого что-либо вышло бы. Более разумно будет зашифровать известный набор таблиц.
Шифруйте данные при первой же возможности. Выполняйте их расшифровку только по требованию и сделайте так, чтобы они не могли храниться где-либо еще.
Резервное копирование данных считается правилом хорошего тона. Нам необходимо выполнять резервное копирование особо важных данных, и те данные, которые определены как наиболее ценные и подлежащие шифрованию, в силу своей важности также достойны резервного копирования! Казалось бы, это очевидно, но мы все же должны убедиться в том, что резервные копии тоже зашифрованы. Это означает, что нам следует знать, какие ключи понадобятся для обработки той или иной версии данных, особенно если эти ключи меняются. Здесь проявляется особая важность наличия четкой системы управления ключами.
Как уже упоминалось, мне не нравится класть все яйца в одну корзину. Я имею в виду глубоко эшелонированную оборону. Мы уже говорили об обеспечении безопасности передаваемых данных и о защите данных, находящихся в покое. Но можем ли мы повысить безопасность, применив какие-то другие средства защиты?
Весьма разумной мерой предосторожности является применение одного или нескольких брандмауэров. Некоторые из них устроены весьма просто и позволяют лишь ограничить доступ определенным типам трафика с помощью конкретных портов. Другие способны на более изощренные действия. ModSecurity, к примеру, является разновидностью приложения-брандмауэра, которое может содействовать дросселированию связи с конкретными диапазонами IP-адресов и определять разновидности попыток взлома.
Имеет смысл воспользоваться более чем одним брандмауэром. Например, вы можете принять решение обеспечивать безопасность хоста локальным использованием таблиц IP-адресов — IPTables, настроив допустимые входы и выходы. Эти правила могут быть привязаны к локально запущенным сервисам, а по периметру может быть выставлен брандмауэр, контролирующий общий доступ.
Качественная регистрация и особенно возможность объединения данных регистрационных журналов нескольких систем не относится к предохранительным мерам, но может способствовать определению причин и ликвидации последствий всевозможных негативных происшествий. Например, после применения исправлений в системе безопасности в журналах зачастую можно наблюдать случаи использования людьми конкретных уязвимостей. Внесение исправлений гарантирует невозможность повторения подобных случаев, но, если это уже произошло, вам может понадобиться перейти в режим восстановления данных. Доступность журналов позволяет отследить наступление неблагоприятных событий.
Но при этом следует иметь в виду, что к информации, которую мы сохраняем в журналах, нужно относиться со всей ответственностью! Конфиденциальную информацию следует отсеивать, чтобы гарантировать отсутствие утечки через журналы важных данных, которые могут стать отличной целью для взломщиков.
Система обнаружения вторжений (IDS) может вести мониторинг сетей или хостов с целью обнаружения подозрительного поведения и оповещения о проблемах по мере их возникновения. Система предотвращения вторжений (IPS) вдобавок к мониторингу подозрительных действий способна вмешиваться в них, не давая им совершиться. В отличие от брандмауэра, который в первую очередь анализирует окружающую обстановку, препятствуя проникновению вредоносного кода, IDS и IPS активно выискивают подозрительное поведение внутри периметра. Когда все начинается с нуля, благоразумнее устанавливать IDS. Эти системы основаны на эвристическом анализе, как и многие приложения-брандмауэры, и вполне возможно, что универсальный стартовый набор правил будет либо слишком мягким, либо недостаточно мягким по отношению к поведению вашего сервиса.
Использование более пассивной IDS-системы для предупреждения о возникающих проблемах может стать неплохим способом настройки правил, прежде чем вы перейдете к использованию более активных возможностей.
При использовании монолитной системы возможности структурирования сетей для предоставления дополнительной защиты ограничены. Но, применяя микросервисы, вы можете поместить их в разных сегментах сети, чтобы получить дополнительный контроль над тем, как сервисы общаются друг с другом. К примеру, AWS дает возможность автоматического предоставления виртуального закрытого облака (VPC), позволяющего хостам находиться в отдельных подсетях. Затем можно указать, какие VPC-облака могут видеть друг друга, установив правила пиринга, и даже направлять трафик через шлюзы для доступа к прокси-серверу, очерчивая фактически несколько периметров, на которых могут быть предприняты дополнительные меры безопасности.
Это дает вам возможность сегментировать сети на основе командной принадлежности или, возможно, степени риска.
Работа систем зависит от большого количества программных средств, создаваемых не нами, и может иметь уязвимости с точки зрения безопасности, которые способны отразиться на нашем приложении (имеются в виду операционные системы и другие вспомогательные средства, под управлением которых оно работает). Здесь вам может пригодиться ряд рекомендаций общего плана. Начните с запуска сервисов исключительно в качестве пользователей операционной системы, имеющих как можно меньше прав доступа, чтобы при компрометации их учетной записи мог быть нанесен минимальный вред.
Затем вносите исправления в свои программные средства. И делайте это регулярно. Этот процесс должен быть автоматизирован, и вы должны быть осведомлены о том, что ваши машины не синхронизированы с самыми последними пакетами исправлений. Здесь могут пригодиться такие средства, как SCCM от компании Microsoft или Spacewalk от RedHat, которые могут оповестить вас о том, что на машине не установлены самые последние исправления, и, если требуется, инициировать обновление программных средств. Если используются такие средства, как Ansible, Puppet или Chef, то проблем с автоматизированным получением изменений у вас, скорее всего, нет, поскольку эти средства могут успешно решать эту задачу, но абсолютно все за вас они делать не будут.
Именно такие средства и нужно использовать, но, как ни удивительно, мне довольно часто приходилось видеть, как весьма важные программные средства запускались на старых операционных системах без внесенных в них последних исправлений. Вы можете использовать наиболее известную и самую защищенную в мире систему безопасности на уровне приложения, но если при этом на вашей машине в качестве основы запущена старая версия веб-сервера с неисправленной ошибкой переполнения буфера, система по-прежнему будет слишком уязвимой.
Если вы используете Linux, то нужно обратить внимание также на наличие модулей безопасности для самой операционной системы. К примеру, AppArmour позволяет определить ожидаемое поведение вашего приложения и в нем имеется ядро, которое будет постоянно следить за приложением. Как только оно начнет делать что-нибудь, чем не должно заниматься, ядро вмешается в его работу. Кроме AppArmour, имеется также SeLinux. Хотя с технической точки зрения оба модуля могут работать на любой современной Linux-системе, на практике некоторые дистрибутивы поддерживают один из них лучше, чем другой. К примеру, AppArmour используется по умолчанию в Ubuntu и SuSE, а SELinux традиционно хорошо поддерживается дистрибутивом RedHat. Самым последним вариантом таких модулей является GrSSecurity, разработанный с прицелом на то, чтобы стать проще в использовании, чем AppArmour или GrSecurity, и с попыткой расширения до их возможностей, но ему для работы требуется собственное ядро. Я бы советовал присмотреться ко всем трем модулям, чтобы понять, который из них вам больше подойдет, но мне нравится идея использования в работе еще одного уровня защиты и профилактики.