Category: Uncategorized

Nginx работает лучше, чем Apache, при том же количестве посетителей, что позволяет посещать ваш интернет-магазин большему количеству посетителей, чем Apache. Nginx не использует файлы .htaccess такие как Apache. Это означает, что конфигурация, ранее выполненная в файлах .htaccess теперь должна выполняться в другом формате.
Блокировка и разрешение IP-адресов осуществляется с помощью модуля доступа gx_http_access_module

Запретить доступ

Чтобы запретить любой доступ с определенных адресов, создайте файл в домашней директории nginx с именем server.blacklist со следующим содержимым:

deny 1.2.3.4; # Deny a single IP
deny 5.6.7.0/24; #Deny a IP range

allow 1.2.3.4; # Allow a single remote host
deny all; # Deny everyone else

location ^~ /myadmin { 
allow 1.2.3.4; 
deny all;
   rewrite / /index.php break;
   echo_exec @phpfpm;
}

if ($http_host ~ "yourdomain.hypernode.io:8443")  {
  set $block_me_now A;
}
 
if ($remote_addr != YOURIP) {
  set $block_me_now "${block_me_now}B";
}
 
 
if ($block_me_now = AB) {
    return 403;
    break;
}

В этом руководстве объясняется, как использовать модуль GeoIP с nginx для блокировки посетителей по странам. Это стало возможным благодаря базе данных GeoIP, которая отображает IP-адреса пользователей по странам. nginx должен быть скомпилирован с HttpGeoipModule для использования базы данных GeoIP.

1 Предварительное примечание

Как упоминалось во введении, nginx должен быть скомпилирован с помощью HttpGeoipModule. Чтобы проверить, был ли ваш nginx скомпилирован с этим модулем, запустите:

nginx -V

Если вы увидите –with-http_geoip_module в выводе, вы готовы использовать базу данных GeoIP с nginx:

root@server1 :~# nginx -V 
 nginx version: nginx/1.2.1 
 TLS SNI support enabled 
 configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-auth-pam --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-echo --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-upstream-fair --add-module=/build/buildd-nginx_1.2.1-2.1-amd64-fMGfEu/nginx-1.2.1/debian/modules/nginx-dav-ext-module 

2 Установка базы данных GeoIP

В Debian / Ubuntu базу данных GeoIP можно установить следующим образом:

apt-get install geoip-database libgeoip1

Эта команда помещает базу данных GeoIP в /usr/share/GeoIP/GeoIP.dat .

Возможно, эта немного устарела. Поэтому мы можем при желании загрузить свежую копию с веб-сайта GeoIP:

mv /usr/share/GeoIP/GeoIP.dat /usr/share/GeoIP/GeoIP.dat_bak

cd /usr/share/GeoIP/ 
 wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz 
 gunzip GeoIP.dat.gz

3 Настройка nginx

Откройте /etc/nginx/nginx.conf …

vi /etc/nginx/nginx.conf

… и поместите в блок http {} перед строками включения :

[...]
    geoip_country /usr/share/GeoIP/GeoIP.dat;
    map $geoip_country_code $allowed_country {
        default yes;
        FK no;
        FM no;
        EH no;
    }
[...]

Вход разрешен всем странам, кроме трех, для которых установлено значение no. Чтобы сделать  наоборот, т.е. заблокировать все страны и разрешить только несколько, вы должны сделать следующим образом:

[...]
    geoip_country /usr/share/GeoIP/GeoIP.dat;
    map $geoip_country_code $allowed_country {
        default no;
        FK yes;
        FM yes;
        EH yes;
    }
[...]

На самом деле не блокирует ни одну страну, а просто устанавливает переменную $ allow_country . Чтобы фактически заблокировать страны, вы должны открыть конфигурацию vhost и поместить следующий код в контейнер сервера {} (это может идти как внутри, так и за пределами любого блока местоположения {} ):

[...]
        if ($allowed_country = no) {
            return 444;
        }
[...]

Возвращает код ошибки 444 любому посетителю из заблокированной страны. Что происходит, закрывается соединение без отправки каких-либо заголовков. Вы также можете использовать другой код ошибки, например 403 («Запрещено»), если хотите.

Перезагрузите nginx для применения:

/etc/init.d/nginx reload

Да. Как правило, в диспетчере ARM по умолчанию существует три домена обработки отказа. Если управляемые диски, которые повышают стабильность работы набора доступности Availability Set за счет изоляции дисков, используемых виртуальной машиной, изолированы, количество доменов сбоя варьирует в пределах 2—3 доменов. Более полную информацию можно найти в документе по адресу: https://docs. microsoft.com/en-us/azure/virtual-machines/windows/ manage-avai lability.

Продолжаем тему, основные вопросы для проведения ИТ аудита, и предлагаем вашему вниманию таблицу с вопросами для обследования серверного помещения.

В данной статье мы продолжаем тему основных вопросов для ИТ аудита. Мы уже рассказали о вопросах аудита безопасности и аудита резервного копирования. Теперь перейдем к оборудованию и ПО.

Компания MongoDB предоставляет простые для использования и реализации собственные средства шифрования и варианты сторонних решений управления ключом шифрования и занимает ведущее место среди поставщиков баз данных, отличных от SQL.

Многие компании, использующие решение MongoDB, ставят во главу угла безопасность данных. Эта статья познакомит вас с основными концепциями шифрования данных в MongoDB и защиты ключей шифрования с использованием корпоративных средств управления ключами шифрования.

Менее чем за десять лет компания MongoDB превратилась в ведущего поставщика не реляционных баз данных, превзойдя таких гигантов рынка систем управления базами данных, как Oracle Database и Microsoft SQL Server.

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

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

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

Чтобы представить полную картину оптимальных путей развертывания и управления ключами шифрования в MongoDB, начнем с рассмотрения вариантов шифрования данных в базе данных MongoDB. Если вам нужно предварительно освоить принципы шифрования и управления ключами, то обратитесь к подробному руководству The Definitive Guide to Encryption Key Management Fundamentals.

MongoDB — не реляционная база данных, отличная от базы данных на основе языка запросов SQL. Это означает, что пользователи могут вводить данные в MongoDB, не определяя таблицы и поля и не назначая индексы. У хранилищ данных такого типа много преимуществ, в том числе возможность добавлять информацию о единичной записи, которая не имеет соответствующего столбца.

Базы данных, отличные от SQL, являются предпочтительным репозиторием для Больших Данных, поскольку они проектировались для хранения огромных объемов не реляционных данных и быстро масштабируются в соответствии с различными нуждами компании. Ни один тип базы данных не лучше другого, они просто предназначены для различных задач, однако при шифровании полезно иметь представление об их сходствах и различиях. Базы данных на основе SQL, или реляционные базы данных, во многом похожи на электронную таблицу.

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

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

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

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

Базам данных, не построенным на базе SQL, таким как MongoDB, отчасти свойственны те же проблемы. Главное различие между двумя типами в том, что, поскольку в не реляционных базах данных данные не разделены по столбцам, шифрование на уровне столбцов невозможно. Поэтому пользователи могут шифровать данные только на уровне приложения или базы данных.

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

Если вы предпочитаете шифровать свои данные, имейте в виду, что MongoDB располагает решениями для шифрования как при пересылке, так и в хранилище.

Шифрование данных при пересылке

Для защиты пересылаемых данных все версии MongoDB поддерживают протоколы TLS (Transport Layer Security) и SSL (Secure Socket Layer) для приема и передачи данных по сети. TLS и SSL — варианты шифрования, широко используемые для зашиты трафика веб-сайтов и обмена файлами.

Это протоколы шифрования для защиты данных, пересылаемых из одной точки в другую; однако, прежде чем данные отправляются, и после того, как прибывают в конечную точку, они оказываются не зашифрованными. MongoDB предоставляет обширную документацию по настройке протоколов TLS и SSL с использованием сертификатов и пары открытого и закрытого ключей, также именуемой системами асимметричных ключей.

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

Закон об ответственности и переносе данных о страховании здоровья граждан и Закон о применении медицинских информационных технологий в экономической деятельности и клинической практике (HIPAA/HITECH) требуют электронной защиты информации о состоянии здоровья. Существует также много других нормативных актов, требующих надежной защиты персональных данных.

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

Шифрование данных в хранилище

Для шифрования неактивных данных в MongoDB Enterprise используется собственный механизм шифрования с симметричным ключом на основе хранилища на уровне файлов. Шифрование всей базы данных также именуется прозрачным шифрованием данных (TDE). Начиная с версии 3.2 MongoDB использует 256-разрядный алгоритм шифрования AES с единственным секретным ключом, применяемым для шифрования и восстановления данных.

MongoDB также предоставляет возможность включить шифрование в режиме FIPS. Это означает, что механизм шифрования, используемый в MongoDB, протестирован Национальным институтом стандартизации и технологии (NIST) на соответствие Федеральному стандарту обработки информации (FIPS). Такие решения построены в соответствии со строжайшими стандартами и требованиями.

Проверка алгоритма шифрования на соответствие NIST FI PS часто требуется для подрядчиков госучреждений и министерства обороны в Северной Америке; однако сегодня большинство регуляторов считают алгоритм AES с сертификатом NIST отраслевым стандартом. Как правило, регуляторы требуют, чтобы этот стандарт шифрования отвечал требованиям нормативных актов. Шифрование AES для неактивных данных доступно только в редакциях MongoDB Enterprise и Atlas с обязательной подсистемой хранилища WiredTiger.

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

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

MongoDB настоятельно рекомендует корпоративное решение управления ключами от стороннего поставщика; однако пользователи могут сохранить ключ локально с помощью файла ключей. Второй вариант связан с очень высоким риском и почти никогда не рекомендуется для зашиты ключей.

Влияние на производительность

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

Когда приложение для банковской сферы или розничной торговли должно ежедневно вызывать миллионы записей из базы данных, любая задержка или простой могут серьезно повлиять на деятельность компании. Поэтому специалисты MongoDB выполнили тесты производительности на процессорах Intel Xcon Х5675.

При работе с максимальной нагрузкой средняя задержка подсистемы хранения с шифрованием составляет от 10 до 20%, в зависимости от количества данных, читаемых или записываемых пользователем в базу данных. Когда пользователь записывает в базу данных только большие объемы данных, влияние на производительность велико; однако гораздо чаше пользователь выполняет в основном команды только для чтения данных, и в большинстве организаций этот показатель составит, скорее всего, 5-10%.

В целях оптимизации шифрования MongoDB шифрует каждую базу данных с использованием зашифрованной подсистемы хранения WiredTiger. MongoDB приобрела WiredTiger в 2014 году, и она стала подсистемой хранения по умолчанию для MongoDB начиная с версии 3.2.

WiredTiger оптимизирована для высокой производительности, масштабирования и безопасности — все эти характеристики соответствуют ценностному предложению MongoDB. Кроме того, WiredTiger дополнительно оптимизирует шифрование благодаря шифрованию файла базы данных на уровне страниц.

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

Таким образом, MongoDB предоставляет мощное решение для шифрования неактивных данных, отвечающее нуждам безопасности и производительности большинства пользователей. Тестирование NIST FIPS обеспечивает соответствие требованиям нормативных актов, а передовая подсистема хранения WiredTiger автоматически учитывает меняющиеся нужды пользователей в сфере безопасности.

Пользователям MongoDB доступно несколько сторонних решений шифрования, но вряд ли эти решения удастся легко масштабировать вместе с вашим экземпляром MongoDB.

Управление ключами шифрования в MongoDB

Шифрование ключей шифрования — метод, используемый для зашиты и управления ключами шифрования. Термин «управление ключами» вызывает некоторую путаницу, поскольку простую запись ключа шифрования на липкой бумажке, которую прячут в выдвижной ящик стола, тоже можно рассматривать как управление ключом.

Однако в контексте этой статьи под ним подразумевается то, что специалисты по безопасности данных называют корпоративным или профессиональным управлением ключами. Корпоративное шифрование ключей должно соответствовать инфраструктуре управления ключами и рекомендациям NIST, сформулированным в специальных публикациях SP-800-130 и SP-800-57.

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

MongoDB не располагает корпоративным решением управления ключами шифрования, и пользователям приходится покупать решение у стороннего поставщика. MongoDB позволяет пользователям управлять ключами шифрования с помощью стороннего поставщика через стандартный протокол управления ключами Key Management Interoperability Protocol (KM IP).

KM IP поддерживается в выпусках MongoDB Enterprise и дает пользователям возможность защитить шифрование с помощью нескольких проверенных партнеров по управлению ключами шифрования. MongoDB позволяет управлять главным ключом шифрования в локальном файле, однако применять этот метод защиты ключей не рекомендуется.

Если вы ищете сторонние решения, которые помогут надежно управлять ключами, обязательно выясните, имеет ли сервер управления ключами (виртуальный или аппаратный) сертификат NIST FI PS 140—2 и/или PCI. Эти сертификаты гарантируют, что программа управления ключами протестирована независимыми организациями и соответствуют высочайшим стандартам технологии управления ключами.

По вопросам усиления безопасности сервера и сайта свяжитесь с нами office@itfb.com.ua

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

Конечно же это не все вопросы, а только начальные, общие, получая ответы на вопросы, углубляемся в процесс.
Какие бы Вы еще выделили вопросы для аудита, пишите в комментариях.

Проведение ИТ аудита, важная задача для любой компании. Благодаря аудиту можно понять реальное состояние ИТ инфрастуктуры, определить критические замечания и приступить к их исправлению. Предлагаем вашему вниманию несколько таблиц, которые содержат список вопросов для аудита ИТ инфраструктуры, по основным направлениям:

• Резервное копирование, восстановление
• Безопасность
• Спецификация оборудования и ПО
• ЦОД
• Политики и процедуры
• Веб

Начнем с перечня вопросов для аудита состояния резервного копирования системы.