Каковы лучшие методы настройки веб-серверов? [закрыто]

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

Из цели корпоративного проектирования вам необходимо узнать о том, что называется «многоуровневой архитектурой». В основном у вас есть отдельные уровни и уровни, которые будут обеспечивать изоляцию и разделение компонентов. Например, у вас может быть уровень представления, на котором работает веб-сервер, такой как NGINX, который в зависимости от использования клиентом может запускать некоторые типы веб-сайтов или действовать как обратный прокси для уровня приложений. Если задействовано корпоративное приложение, оно должно быть на уровне приложения, где оно будет работать на собственных выделенных ресурсах и промежуточном программном обеспечении, таком как сервер приложений WebSphere или JBoss EAP. Затем для уровня базы данных разместите здесь свои базы данных с их собственными ресурсами. Это могло бы выглядеть так:

Pres. Уровень ( Apache / NGINX) <--> App. Уровень (WAS / JBoss ) <--> Уровень базы данных (Oracle / Postgres / SQL)

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

Затем каждый узел также должен быть усилен с помощью какая-то структура вроде NIST 800-53 или 800-171. Не позволяйте этому ошеломить вас, просто найдите время для внедрения, тестирования и написания необходимых изменений, а также создайте GPO и предварительно защищенные образы. Кроме того, если к вам не предъявляются какие-либо конкретные требования, вы можете свободно применять то, что лучше всего подходит для вашей организации. CIS-CAT - это еще один фреймворк, и у них есть некоторые базовые бесплатные инструменты, но для работы со всеми типами систем вам может потребоваться членство.

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

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

Это только верхушка айсберга, но этого должно быть достаточно, чтобы вы начали работу над дизайном. Если вы покупаете новое оборудование, вы можете рассмотреть вариант корпуса Dell VRTX с блейд-модулями. У вас может быть два таких центра в разных центрах обработки данных и выполнять полное резервирование и аварийное переключение. Или просто возьмите один с 2 лезвиями и запустите кластерный хост. Просто заполните ОЗУ и диски, загрузите предпочтительный гипервизор виртуализации и создайте свой кластер. Если у вас ограниченный бюджет Ubiquiti имеет доступное сетевое оборудование, но их БЕСПЛАТНАЯ поддержка предоставляется только в чате. В противном случае Cisco является «золотым стандартом», но вы платите за поддержку TAC и ежегодные обновления, или вы не получаете обновлений безопасности или поддержки по телефону, которые, если у вас нет на это бюджета, держитесь подальше.

Наконец, Я бы попытался сформулировать еще несколько вещей. Вам необходимо определить бюджет и каковы требования КАЖДОГО из ваших 300 клиентов, и могут ли некоторые из них совместно использовать размещенное пространство (подумайте о плане общего хостинга), когда производительность не является главным приоритетом и создает любые дыры в безопасности, которые могут возникнуть у другого клиента. не разрешено. То, что хотят клиенты, может быть нереалистичным по их цене даже с облачным провайдером, потому что, когда вы получаете виртуальную машину, вы не получаете никакого усиления защиты или управления безопасностью, поэтому вы все равно несете за это ответственность. С безопасностью это как качели на скользящих весах с удобством использования. Если он полностью пригоден для использования, он небезопасен, но если он полностью безопасен, никто не может получить к нему доступ. Вам нужно будет определить, где вы должны быть для этого, и это может быть разным для разных клиентов. В этих вещах нет серебряной пули. Большинство разработчиков не рассматривают безопасность как часть своей разработки, поэтому планируйте, что что-то сломается, когда вы станете более защищенным. Неисправные элементы можно исправить с помощью правильного кодирования и / или архитектурного проектирования.