В настоящее время наша компания имеет кластер, ориентированный на клиентов, для наших регистраций и управления учетными записями клиентов, которые имеют прямой доступ к действующей базе данных (один главный плюс несколько подчиненных устройств только для чтения).
Недавно у нас было несколько дискуссий об улучшении безопасности этой установки (помимо существующих брандмауэров). Идея (исходящая от руководства) заключается в том, что производственные серверы не должны иметь прямого доступа для чтения или записи в базу данных, а вместо этого что-то должно запускаться либо с сервера базы данных, либо с какого-либо другого внутреннего сервера, который подключается к производственным серверам и запрашивает информацию от существовала какая-то временная очередь.
Так
В настоящее время:
Приложение записывает новые регистрации в базу данных Приложение считывает данные о клиентах из базы данных
(App -> DB)
Предложил:
Приложение записывает новые регистрации во временный локальный кеш (это может быть файловая система, временная база данных, memcached и т. Д.). Cron / демон из внутренней сети подключается OUT к серверу приложений и получает запросы к базе данных в очереди. Cron / daemon записывает новые данные в базу данных или считывает старые данные из базы данных. как просили
Cron / daemon отправляет результат на сервер приложений
(App <- Daemon -> DB)
Мне как разработчику (а не системному администратору) это кажется смешным, но я с готовностью признаю, что не являюсь экспертом по безопасности. В качестве альтернативы я предложил, чтобы, если у нас не было прямого доступа к БД, мы могли бы иметь промежуточный уровень, который принимает структурированные запросы, генерирует запросы к БД и возвращает данные. Это было бы больше похоже на
(App -> Proxy -> DB)
Ответ руководства состоит в том, что это неоптимально (но, по крайней мере, это все еще обсуждается).
Я предполагаю, что этот тип аргументов повторялся много раз во многих местах, но я не видел ничего, что конкретно касалось бы плюсов или минусов их предлагаемой архитектуры. Действительно ли предложенный обратный прокси-подход намного более безопасен, чем стоит потраченного времени на его создание? Если нет, то что бы вы использовали для подтверждения вашего аргумента, если бы вас попросили реализовать такую архитектуру.
От какой конкретной уязвимости они хотят избавиться? Похоже, много дополнительных накладных расходов и сложности (что неизбежно приводит к проблемам того или иного рода).
Если серверы приложений по-прежнему имеют доступ к серверам баз данных через прокси-сервер или другого посредника, сервер приложений с корневым доступом может по-прежнему создавать запрос, который направляет базу данных. Я просто не вижу в предложении особой дополнительной безопасности; возможно, я что-то упускаю.
Безопасность - это не какая-то туманная или взаимозаменяемая «вещь», которую вы можете добавить через неясность или сложность. Безопасность - это особые меры, принимаемые для смягчения конкретных угроз.
Производственные серверы не должны быть внешними. Типичная модель - это трехзонная модель: внешняя, DMZ (демилитаризованная зона) и внутренняя. Внешний никогда не должен иметь доступ к Внутреннему. Однако серверы Productions должны находиться в DMZ. Серверы DMZ должны иметь ограниченный доступ к внутренней сети. Доступ из DMZ должен быть основанием с минимальными привилегиями.
Для этого типа приложений я бы предоставил доступ к службам во внутренней сети, которые выполняют необходимые действия. Это должен быть ограниченный набор действий, которые могут обновлять данные одного клиента за раз.
Общий доступ из DMZ подвергает риску ваши данные, если кто-то взломает рабочий веб-сервер.