Лучшие практики для защиты данных веб-сервера

Question

Допустим, я управляю медицинским учреждением и хочу веб-сайт, где мои пользователи / пациенты могут просматривать свои личные записи. Каково было бы лучшее решение против наиболее распространенных атак?

Даже если я использую частный сервер, купленный где-то, и полагаюсь на его службы мониторинга, есть большая вероятность, что кто-то сможет найти дыру в безопасности и украсть мои данные. Конец моего бизнеса.

Каковы лучшие практики для такой архитектуры?

Answer 1

Сначала вам нужно определить атаки, от которых вы хотите попытаться защитить себя, а затем рассмотреть каждую из них в отдельности. Поскольку вы упоминаете "наиболее распространенные атаки", мы начнем с них; Вот краткий список для обычной трехуровневой службы (client-web-datastore):

1. Поврежденные входы (ручные или размытые)
2. SQL-инъекция
3. Межсайтовые скриптовые атаки ( XSS)
4. Гадание: перебор, словарь, радужные таблицы и т. Д.
5. На месте (сотрудник) утечки
6. Социальная инженерия
7. Человек посередине
8. Межсайтовые подделки ( CSRF)
9. Переиграть атаки

В случае утечки или взлома, вот некоторые из проблем, которые облегчают злоумышленникам, и, следовательно, также должны быть решены:

• Данные хранятся в виде простого текста
• Слабые пароли / ключи
• Слабое шифрование или хэши
• Нет соления
• Нет разделения служб (например, размещение базы данных в том же физическом блоке, что и веб-сервер)

Теперь мы посмотрим на общие меры по смягчению:

1-3 (Входные данные, SQL-инъекция, XSS) часто имеют дело с неправильными входными данными. Таким образом, все входные данные от клиента должны быть подвергнуты дезинфекции, и для обеспечения правильной работы кода необходимо выполнить (сфокусированное на атаках) тестирование.

4 (Угадай). Автоматические инструменты будут использоваться, чтобы попытаться угадать пароль пользователя, или, если у них уже есть данные, они попытаются форсировать ключ или хэш. Смягчающие меры включают выбор правильного алгоритма шифрования или хэширования. Увеличение размера бита ключа. Применение политик в отношении сложности пароля / ключа. Использование солей. Ограничение количества попыток в секунду. и т.п.

5 (Утечки) Если данные зашифрованы на месте, и у администраторов / сотрудников / уборщиков нет ключей для расшифровки данных, то утечка информации имеет ограниченную ценность (особенно если #4 обрабатывается правильно). Вы также можете наложить ограничения на то, кто и как может получить доступ к данным (АНБ только что усвоил здесь ценный урок и проводит политику, обеспечивающую присутствие двух человек для доступа к частным данным). Правильная регистрация и регистрация попыток доступа также важны.

6 (Социальная инженерия) Злоумышленники попытаются позвонить в вашу службу поддержки, выдать себя за клиента и либо запросить доступ к привилегированной информации, либо попросить службу поддержки изменить информацию (пароль, личную информацию и т. Д.). Они часто объединяют несколько звонков в службу поддержки, пока не получат всю информацию, необходимую для управления учетной записью. Служба поддержки должна быть обучена и ограничена в том, какую информацию они будут предоставлять, а также какие данные они могут редактировать.

7 ("Человек посередине"). Здесь злоумышленник пытается внедрить себя в поток обмена данными, чаще всего с помощью руткитов, работающих на клиентских компьютерах или поддельных точек доступа (например, WiFi). Проводное / протокольное шифрование (например, SSL), очевидно, является первым уровнем защиты. Но варианты (такие как "человек в браузере") не будут смягчены, поскольку они будут видеть данные после расшифровки пакетов SSL. Как правило, клиентам нельзя доверять, поскольку сами платформы небезопасны. Хорошая практика - поощрять пользователей к использованию выделенных / изолированных машин. Ограничьте время хранения ключей и расшифрованных данных в памяти или других доступных местах.

8-9 (CSRF и воспроизведение) Подобно тому, как человек посередине, эти атаки будут пытаться дублировать (например, перехватывать) учетные данные пользователя и / или транзакции и использовать их повторно. Аутентификация по клиентскому происхождению, ограничение окна, когда учетные данные действительны, требующая проверки транзакции (через отдельный канал, такой как электронная почта, телефон, SMS и т. Д.) - все это помогает уменьшить эти атаки.

Правильное шифрование / хеширование / засоление - это, пожалуй, первое, что испортят компании. Предполагая, что все ваши другие падения обороны (и, как вы сказали, они, вероятно, будут), это ваша последняя надежда. Инвестируйте здесь и убедитесь, что это сделано правильно. Убедитесь, что отдельные записи пользователя закодированы разными ключами (а не одним главным ключом). Если клиент выполняет шифрование / дешифрование, это может решить множество проблем безопасности, поскольку сервер никогда не знает ключей (поэтому никто не может их украсть). С другой стороны, если клиент потеряет ключи, он также потеряет свои данные. Таким образом, компромисс должен быть достигнут там.

Инвестируйте в тестирование / атаку вашего решения. Инженер, который реализует веб-сайт / базу данных, часто не способен думать обо всех возможных сценариях атаки.

Answer 2

Ваш вопрос: каковы лучшие практики для такой архитектуры?

Мне нравится эта статья от Microsoft Security Best Practices to Protect Internet Facing Web Servers, который имел 11 ревизий. Конечно, некоторые из них относятся к конкретной платформе Microsoft, множество концепций, которые можно применить к независимому от платформы решению.

1. Определите сетевой поток с точки зрения запросов: если вы знаете обычный сетевой поток, который сервер должен принимать и отправлять, то вы можете разрешить и проверить (проверка содержимого / запросов) их, тогда как другой трафик / поток будет отклонен по умолчанию. (через брандмауэр). Это мера изоляции сети, которая снизит риск распространения вредоносного ПО (или успешного проникновения в глубину производственной сети).
2. Убедитесь, что ваша DMZ не имеет возможности прямого доступа к вашей локальной сети с помощью правила "источник к любому" или "источник ко многим" (правила брандмауэра / маршрутизаторов должны быть перепроверены).
3. Убедитесь, что нет способа напрямую запросить ваш веб-сервер, минуя слои фильтрации безопасности. Для вашего веб-сервера должен быть хотя бы трехслойный фильтр:
   1. Протоколы и источники принимаются: брандмауэр (и маршрутизаторы).
   2. Динамическая проверка сетевого трафика: NIPS (Network Intrusion Protection System), которая будет обнаруживать / блокировать вредоносные сетевые запросы. Возможно, вы захотите взглянуть на MAPP, чтобы найти партнера Microsoft (www.microsoft.com/security/mapp/ Эта ссылка является внешней для TechNet Wiki. Она откроется в новом окне.). Также имейте в виду, что NIDS будет стремиться только обнаруживать, а не блокировать вредоносный трафик (в отличие от NIPS), но, с другой стороны, они не будут создавать какой-либо риск отказа в обслуживании для бизнес-потоков.
   3. Безопасность, ориентированная на приложения: WAF (брандмауэр веб-приложений), расположенный рядом с веб-приложением / сайтом, который позволит усилить контроль над запросами и усилить фильтр в соответствии со спецификой веб-приложения. ModSecurity для IIS7 (см.: http://www.modsecurity.org/ Эта ссылка является внешней для TechNet Wiki. Она откроется в новом окне.) Является примером инструмента, который можно использовать для надежного ведения журнала аудита HTTP(S) транзакции и виртуальное исправление выявленных уязвимостей. Наряду с комплектом базовых правил OWASP ModSecurity (CRS) он обеспечивает необходимую защиту от атак на уровне приложений и утечек информации.
4. Убедитесь, что клиенты не могут напрямую отправлять запросы на ваш сервер (с точки зрения TCP), в противном случае это может способствовать атакам. Таким образом, обеспечьте изоляцию сети с учетом DMZ, развернув обратный прокси-сервер в качестве внешнего интерфейса веб-сервера. Это позволит легче управлять сетевым потоком, который может быть законно отправлен на сервер (включая другие потребности, такие как балансировка нагрузки). Примером такого решения может быть Forefront UAG или любое другое из программы MAPP. Обратите внимание, что некоторые обратные прокси могут предлагать расширенные функции безопасности.
5. Следуйте рекомендациям по безопасности для кода ASP.Net для защиты от внедрения кода: http://msdn.microsoft.com/en-us/magazine/hh580736.aspx Эта ссылка является внешней для TechNet Wiki. Он откроется в новом окне. и SQL-инъекция: http://msdn.microsoft.com/en-us/library/ms161953(SQL.105).aspx Эта ссылка является внешней для TechNet Wiki. Он откроется в новом окне., С более глобальной точки зрения, пожалуйста, обратитесь к SDL: http://msdn.microsoft.com/en-us/security/aa570401.aspx Эта ссылка является внешней для TechNet Wiki. Он откроется в новом окне., Проверяйте размещенный код на регулярной основе.
6. Максимально укрепите зашифрованные сетевые коммуникации, принимая во внимание доступные реализации SSL/TLS в системах Windows, которые вы используете: http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/07/secure-channel-compatibility-support-with-ssl-and-tls.aspx Эта ссылка является внешней для TechNet Wiki. Он откроется в новом окне., По умолчанию наша рекомендация - TLS 1.1/1.2. Пожалуйста, имейте в виду, что это должно быть включено как на стороне клиента, так и на стороне сервера.
7. Убедитесь, что машины в DMZ не подключены к обычному производственному домену. Изоляция АД находится на лесном ярусе, поэтому настоятельно рекомендуется не иметь АД производства в ДМЗ. Пожалуйста, используйте другой лес или разверните AD Lightweight Directory Services.
8. Реализация белых / черных списков приложений, например, через AppLocker: http://technet.microsoft.com/en-us/library/ee791890(v=ws.10).aspx Эта ссылка является внешней для TechNet Wiki. Он откроется в новом окне.
9. Убедитесь, что у вас есть вся соответствующая (и необходимая?) Цепочка прослеживаемости: это означает возможную корреляцию между журналами брандмауэра, обратного прокси-сервера и веб-сервера. Пожалуйста, обратите внимание, чтобы не только включить регистрацию ошибок, например, в журналах IIS. Наконец, рассмотрите возможность архивирования журналов.
10. Регулярно создавайте резервные копии данных веб-сервера.
11. Создавайте образы систем в целочисленном состоянии на регулярной основе (по крайней мере, во время развертывания). Это может быть полезно в случае инцидента безопасности как для скорейшего возврата в рабочий режим, так и для расследования.
12. Проверяйте свое оборудование: правила брандмауэра, правила NIPS, правила WAF, настройки обратного прокси-сервера на регулярной основе.
13. Следуйте рекомендациям по безопасности продуктов уровня приложений, уровня базы данных и уровня веб-сервера.

ссылка: http://social.technet.microsoft.com/wiki/contents/articles/13974.security-best-practices-to-protect-internet-facing-web-servers.aspx

Answer 3

Хотя Джош Поли и Бала Субраманьям- хорошие ответы, я бы добавил, что если основная ценность вашего бизнеса - безопасность, вы должны:

• Наймите лучших хакеров по безопасности, заплатите им очень хорошо и заставьте их гордиться работой в вашей компании.
• Наймите лучших программистов оттуда, заплатите им очень хорошо и заставьте их гордиться работой в вашей компании.
• Разместите свои серверы в своих собственных зданиях, возможно, на разных долготах

Хакеры и разработчики будут вашим главным активом, и они должны это знать. В самом деле, мы можем перечислить здесь самые распространенные методы обеспечения безопасности, но, применяя наши предложения, вы не сделаете свою систему по-настоящему безопасной, просто взломать ее.

Когда безопасность важна, ваши таланты, страсть и компетентность - ваша единственная защита.

Answer 4

Хорошо, я просто попытаюсь немного рассказать о том, что вы уже предложили. Во-первых, вы можете изучить технологии, стоящие за мега- сайтом; он использует, по-видимому, именно то, что вам будет интересно. Однако шифрование на основе JS все же имеет некоторые недостатки. Тем не менее, было бы нелегко осуществить расшифровку записей на лету с помощью js и html, хотя это и невозможно. Таким образом, да, я бы сказал, что вы в целом думаете в правильном направлении.

В любом случае вам придется рассмотреть все распространенные методы и способы защиты (атаки на веб-сайты, серверные атаки и т. Д.), Но эта тема слишком широка, чтобы ее можно было полностью и полностью охватить одним ответом. И, разумеется, они уже очень хорошо освещены в других ответах.

Что касается "архитектуры", если вы действительно параноик, у вас также может быть база данных на отдельном сервере, который запускает базу данных через непонятный порт и разрешает входящие соединения только с веб-сервера.

Answer 5

Вот о чем я думаю:

Все записи хранятся на моем домашнем компьютере (вавтономном режиме) в зашифрованном виде с помощью моего личного ключа. На этом компьютере есть записи о пациентах, а также закрытый и открытый ключи для каждого пользователя. Этот компьютер загружает новые данные, как есть, шифратор на веб-сервер.

Веб-сервер содержит только зашифрованные данные.

Я предоставляю открытый ключ своим пользователям. Будь то электронная почта, отправленная откуда-то еще, или даже обычной почтой.

Веб-сервер расшифровывает данные по каждому запросу. Поскольку пароль пользователя является его открытым ключом, расшифровка на сервере может происходить только во время активного сеанса.

Поскольку в игре присутствуют асимметричные ключи, я даже могу вставить новые зашифрованные данные на веб-сервер (пользовательский ввод) и затем загрузить их на мой офлайн-компьютер.

Недостаток: для запроса нового пароля требуется, чтобы офлайн-компьютер загружал повторно зашифрованные данные и каким-либо образом отправлял новый пароль.

Перевернутая: делает проблемы безопасности веб-сервера менее актуальными.

Это лучшее решение?