Краткая справка. Мы небольшая компания (13 сотрудников, 6 из которых IT / разработчики). Все работают удаленно, центрального офиса нет. Наш центр обработки данных используется только для сред разработки и производства. Мы не используем его для каких-либо внутренних функций компании (например, в настоящее время доступ к VPN есть только у ИТ-специалистов, и мы используем такие вещи, как Office365 / OneDrive, а не файловый сервер в нашей сети). Мы разрабатываем, размещаем и продаем решение SaaS. Мы немного занимаемся медицинскими данными (например, HIPAA и PHI), поэтому мы прошли процесс сертификации HIPAA и NIST, что очень важно для наших клиентов.
Текущая инфраструктура
У нас есть полустойка в центре обработки данных с кластерной средой Hyper-V (3 физических сервера, подключенных к Nimble SAN). Наша среда состоит из:
Мы уже используем хранилище Azure для хранения клиентских документов, а также для резервного копирования вне офиса. У нас также есть сайт холодного аварийного восстановления, настроенный в Azure, состоящий из трех виртуальных машин (AD, Web и DB), который, хотя и минимален, позволит нам развернуть нашу основную инфраструктуру в Azure в течение нескольких часов.
Планируйте вперед
Наша цель (в идеале до конца 2019 года) - переехать из центра обработки данных в Azure. Наше текущее оборудование стареет, и, не показывая никаких признаков сбоя (удары по дереву), мы хотим избавиться от необходимости беспокоиться о физическом оборудовании центров обработки данных, когда такие компании, как Microsoft (или Amazon / Google и т. Д.), Намного больше способен на это. У меня в голове есть приличное представление о том, как это сделать, и я играл с Azure в течение последнего месяца, чтобы ознакомиться с вариантами.
С точки зрения высокого уровня я смотрю на такую простую вещь, как это развертывание (https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/basic-web-app) для нашего приложения. Мы рассматривали возможность повторного создания существующих виртуальных машин непосредственно в Azure, но переход на PaaS гораздо более привлекателен с точки зрения обслуживания. Основное отличие будет заключаться в том, что мы будем использовать управляемый экземпляр SQL для нашей базы данных вместо базы данных SQL. Эта архитектура предназначена только для нашей производственной среды. Для нашей среды разработки / контроля качества мы, скорее всего, развернем ту же или похожую архитектуру в отдельной группе ресурсов и виртуальной сети.
Мои самые большие вопросы вращаются вокруг того, подходит ли сюда брандмауэр. Мы получаем анкеты по ИТ и должны пройти полный аудит безопасности ИТ с большинством наших клиентов. Вот примеры вопросов, которые мы получаем:
Практически во всех примерах, которые я нашел до сих пор, рекомендуемые развертывания Azure не включают ничего, связанного с брандмауэром или IDS / IPS. Это довольно стандартно? Я знаю, что брандмауэр Azure существует, но при цене 900 долларов в месяц он не имеет смысла из-за ограниченной защиты, которую он обеспечивает поверх групп безопасности сети. Я начал рассматривать вариант NVA (особенно Netgate pfSense, потому что я очень хорошо знаком с pfSense), но я не знаю, будет ли это излишним?
Итак, если вы все еще читаете после долгого выученного плана, я думаю, что я спрашиваю:
Требования к безопасности и соответствию защищенной информации, позволяющей установить личность (PII), отличаются от требований в менее регулируемых отраслях. (И особенно по сравнению с учебными пособиями для начинающих с минимальным дизайном безопасности.) В дополнение к нарушению доверия пациента с помощью очень личной информации, в некоторых юрисдикциях налагаются штрафы. В США люди склонны ссылаться на Закон 1996 года о переносимости и подотчетности медицинского страхования (HIPAA) и его правила о защищенной медицинской информации (PHI). Штрафы могут быть начислены за каждую затронутую запись, и они будут хуже, если они вызваны пренебрежением.
Вопросы о брандмауэре могут начать разговор о ваших мерах безопасности. Но они не являются полной программой безопасности.
Конечно, должны быть установлены межсетевые экраны уровня 4 для управления по IP (в Azure, Группа безопасности приложений) и порт. Также рассмотрите возможность сегментации сети. Должен быть только авторизованный доступ к базам данных, которые содержат PHI, и изолировать тест от производственной среды. Концепции нулевого доверия могут быть полезны в качестве вдохновения. Найдите способ доказать, что правила брандмауэра реализуют ваши намерения.
Вам также нужны способы предотвращения и обнаружения нарушений. Скажем, у вас есть API, который не подвергался ограничениям и не проверялся. Межсетевые экраны сетевого уровня не помогают, когда данные выводятся из порта 443, который изначально открыт для авторизованного использования.
Элементы управления, которые вы можете использовать для этого, включают сильные возможности аудита в вашем приложении и, возможно, IDS / IPS для проверки плохого поведения. Вопрос не только в том, подходит ли вам брандмауэр Azure, а в том, как быстро вы можете показать доказательства несанкционированного доступа, сколько данных было удалено и кто это сделал. Если ни ваши приложения, ни Azure этого не делают, рассмотрите продукты сторонних производителей.
Да, и электронная почта. Как вы собираетесь запретить пользователям отправлять идентификаторы пациентов по электронной почте?
О физической безопасности центра обработки данных заботится Azure. Но применяете ли вы шифрование дисков для ноутбуков сотрудников? Те могли заблудиться с ЗМИ.
Все это и многое другое требует программы безопасности с комплексным планом управления рисками, сильными процессами, которые не забывают основы, и участием руководства. В качестве примера такого подхода к защите взгляните на Руководство SecurityMetric по соответствию HIPAA.
Будьте честны со своими клиентами и аудиторами. Признание любых пробелов и предложение альтернативных средств контроля более правдоподобно, чем заявлять, что все делает.