Рекомендации по защите данных веб-сервера

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

7 (Man-in-the-middle). Здесь злоумышленник попытается внедрить себя в поток связи, чаще всего используя руткиты, запущенные на клиентских машинах или поддельный доступ точки (Wi-Fi, например). Шифрование на основе протокола/протокола (например, SSL), очевидно, является первым уровнем защиты. Но варианты (например, "человек в браузере" ) не будут смягчены, поскольку они будут видеть данные после того, как пакеты SSL будут расшифрованы. В общем, клиентам нельзя доверять, потому что сами платформы небезопасны. Поощрение пользователей использовать специализированные/изолированные машины - хорошая практика. Ограничьте время, в течение которого ключи и дешифрованные данные сохраняются в памяти или в других доступных местах.

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



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

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

Ответ 2

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

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

  • Определите сетевой поток с точки зрения запросов: если вы знаете обычный сетевой поток, который должен получать и отправлять сервер, вы можете разрешить и проверить (проверка содержимого/запросов) в то время как другим трафиком/потоком будет отказано по умолчанию (через Firewall). Это мера изоляции сети, которая уменьшит риск распространения вредоносного ПО (или успешное вторжение, проникающее глубже в производственную сеть).
  • Убедитесь, что у вашей DMZ нет возможности прямого доступа к вашей локальной сети с правилом "источник для любого" или "источником для многих" (правила брандмауэра/маршрутизаторов должны быть дважды проверены).
  • Убедитесь, что нет возможности напрямую запрашивать ваш веб-сервер, минуя уровни фильтрации безопасности. Для вашего веб-сервера должен быть как минимум 3-слойный фильтр:
    • Протоколы и источники: брандмауэр (и маршрутизаторы).
    • Проверка динамического сетевого трафика: NIPS (Network Intrusion Protection System), которая будет обнаруживать/блокировать вредоносные сетевые запросы. Возможно, вам стоит взглянуть на MAPP, чтобы найти партнера Microsoft (www.microsoft.com/security/mapp/Эта ссылка является внешней для TechNet Wiki, которая откроется в новом окне). Также имейте в виду, что NIDS будет стремиться обнаруживать, а не блокировать вредоносный трафик (в отличие от NIPS), но, с другой стороны, они не будут создавать риск отказа в обслуживании для бизнес-потоков.
    • Безопасность, ориентированная на приложения: WAF (брандмауэр веб-приложений), рядом с веб-приложением/сайтом, что позволит упростить управление запросами и затянуть фильтр в соответствии с особенностями веб-приложения. ModSecurity для IIS7 (см. http://www.modsecurity.org/ Эта ссылка является внешней для TechNet Wiki. Она откроется в новом окне.) Является примером инструмент, который может использоваться для надежного аудита протоколов транзакций HTTP (S) и виртуального исправления выявленных уязвимостей. Наряду с комплектом OWASP ModSecurity Core Rule Set (CRS) он предлагает существенную защиту от атак приложений и утечек информации.
  • Убедитесь, что клиенты не могут напрямую отправлять запросы на ваш сервер (с точки зрения TCP), что в противном случае может способствовать атак. Таким образом, обеспечить изолирование сети, DMZ-minded, путем развертывания обратного прокси-сервера в качестве front-end веб-сервера. Это позволит более легко управлять потоком сети, который может быть законно отправлен на сервер (включая другие потребности, такие как балансировка нагрузки). Forefront UAG может быть примером такого решения или любого другого из программы MAPP. Обратите внимание, что некоторые обратные прокси могут предлагать расширенные функции безопасности.
  • Следуйте рекомендациям по безопасности для кода 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. Он откроется в новом окне., Регулярно проверяйте размещенный код.
  • Закрепить зашифрованные сетевые коммуникации, насколько это возможно, принимая во внимание доступные реализации 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. Имейте в виду, что это должно быть включено как на стороне клиента, так и на стороне сервера.
  • Убедитесь, что машины в DMZ не объединены с обычным производственным доменом. Изоляция AD находится в лесу, поэтому настоятельно рекомендуется не производить AD в DMZ. Пожалуйста, используйте другой лес или разверните службы AD Lightweight Directory Services.
  • Внедрить белый/черный список приложений через AppLocker, например: http://technet.microsoft.com/en-us/library/ee791890(v=ws.10).aspx Эта ссылка является внешней для TechNet Wiki. Он откроется в новом окне.
  • Убедитесь, что у вас есть целая цепочка отслеживания (и требуемая?): это означает возможную корреляцию между журналами брандмауэра, обратного прокси и веб-сервера. Пожалуйста, обратите внимание не только на включение журнала ошибок, например, в журналы IIS. Последнее, пожалуйста, рассмотрите архивирование журналов.
  • Создать резервную копию данных веб-сервера на регулярной основе.
  • Создавать изображения систем в целочисленном состоянии на регулярной основе (по крайней мере, во время развертывания). Это может быть полезно в случае инцидента с безопасностью, чтобы как можно быстрее вернуться в режим производства, а также провести расследование.
  • Аудит вашего оборудования: правила брандмауэра, правила NIPS, правила WAF, настройки обратного прокси-сервера, на регулярной основе.
  • Следуйте рекомендациям по безопасности для продуктов уровня приложения, уровня на уровне базы данных и уровня веб-сервера.

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

Ответ 3

В то время как josh poley и Bala Subramanyam - хорошие ответы, я бы добавил, что if основная ценность вашего бизнеса - безопасность:

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

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