Предположим, что я запустил медицинское учреждение и хочу, чтобы сайт, на котором мои пользователи/пациенты могли найти свои личные записи. Что было бы лучшим решением против большинства распространенных атак?
Даже если я использую приватный сервер, купленный где-то, и полагаюсь на его службы мониторинга, есть хороший шанс, что кто-то может найти дыру в безопасности и украсть мои данные. Конец моего бизнеса.
Каковы наилучшие методы для такой архитектуры?
Сначала вам нужно определить атаки, которые вы хотите попробовать и защитить, а затем обратиться к каждому из них по отдельности. Поскольку вы упоминаете "наиболее распространенные атаки", мы начнем там; вот краткий список для общего трехуровневого сервиса (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 и т.д.), Помогают уменьшить эти атаки.
Правильное шифрование/хеширование/соление - это, вероятно, первое, что компании завинчивают. Предполагая, что все ваши другие защиты падают (и, как вы сказали, они, вероятно, будут), это ваша последняя надежда. Инвестируйте здесь и убедитесь, что это сделано правильно. Убедитесь, что отдельные записи пользователя закодированы с помощью разных клавиш (а не одного главного ключа). Наличие клиента делает шифрование/дешифрование может решить множество проблем с безопасностью, поскольку сервер никогда не знает ключей (так что никто не может их украсть). С другой стороны, если клиент теряет ключи, они также потеряют свои данные. Таким образом, нужно будет сделать компромисс.
Инвестируйте в тестирование/атаку вашего решения. Инженер, который реализует веб-сайт/базу данных, часто не оборудован, чтобы думать обо всех возможных сценариях атаки.
Ваш вопрос: Каковы наилучшие методы для такой архитектуры?
Мне нравится эта статья от Microsoft Security Best Practices to Protect Internet Facing Web Servers, у которой было 11 версий. Конечно, некоторые из них являются специфичными для Microsoft-платформы, многие концепции, которые вы можете применить к платформонезависимому решению.
В то время как josh poley и Bala Subramanyam - хорошие ответы, я бы добавил, что if основная ценность вашего бизнеса - безопасность:
Хакеры и разработчики станут вашим основным активом, и они должны это знать. В самом деле, мы можем перечислить наиболее распространенные методы безопасности здесь, но, применяя наши предложения, вы не сделаете свою систему действительно безопасной, просто смешно взломать.
Когда важны вопросы безопасности, ваши таланты, страсть и компетентность - ваша единственная защита.
Вот что я думаю:
Все записи хранятся на моем домашнем компьютере (в автономном режиме), зашифрованном моим личным ключом. Внутри этого компьютера пациент записывает и частный и открытый ключ для каждого пользователя. Этот компьютер загружает новые данные, как есть, в encrypter на веб-сервер.
Веб-сервер содержит только зашифрованные данные.
Я предоставляю открытый ключ своим пользователям. Будь то, используя электронную почту, отправленную из другого места, или даже уличную почту.
Webserver расшифровывает данные по каждому запросу. Поскольку пароль пользователей является его открытым ключом, decription на сервере может произойти только при активном сеансе.
Поскольку в игре есть ассиметричные ключи, я даже могу вставить новые зашифрованные данные на веб-сервере (пользовательский ввод), а затем вывести его на свой автономный компьютер.
Даунсайд. Запрос нового пароля требует, чтобы автономный компьютер загружал повторно зашифрованные данные и каким-то образом отправлял новый пароль.
Поверхность: делает проблемы безопасности веб-сервера менее релевантными.
Это лучшее решение?
Хорошо, я просто попытаюсь немного подстроить то, что вы уже предложили. Во-первых, вы можете изучить технологии mega веб-сайт; он использует, по-видимому, именно то, что вам было бы интересно. Однако на лету шифрование на основе JS все еще имеет некоторые недостатки. При этом было бы непросто реализовать на деле дешифрование записей с помощью js и html, но это не невозможно. Таким образом, я бы сказал, что вы, как правило, думаете в правильном направлении.
Независимо от этого вам придется учитывать все распространенные методы атаки и защиты (атаки на сайты, атаки на сервер и т.д.), но эта тема слишком широка, чтобы полностью и полностью охватывать один ответ. И, разумеется, они уже очень хорошо освещены в других ответах.
Что касается "архитектуры", если вы действительно параноик, вы также можете иметь базу данных на отдельном сервере, который запускает базу данных на неясном порту и позволяет входящие соединения только с веб-сервера.