V1.9.1 Communications Architecture

Requirement:

Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. (C3)

Explanation:

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

1. Data Confidentiality:

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

2. Network Security:

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

3. Protection Against Eavesdropping:

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

4. Compliance Requirements:

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

Рассмотрим приложение на базе микросервисов, развернутое в нескольких контейнерах у разных облачных провайдеров. Чтобы выполнить это требование, можно настроить каждый микросервис на взаимодействие по протоколу HTTPS/TLS, который шифрует передаваемые данные. Приведем пример настройки обратного прокси-сервера NGINX для обеспечения HTTPS для входящего трафика:

server {

listen 443 ssl;

server_name your-domain.com;

ssl_certificate /etc/nginx/ssl/your-cert.pem;

ssl_certificate_key /etc/nginx/ssl/your-key.pem;

# Other SSL/TLS configuration options...

location / {

proxy_pass http://your-backend-service;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

# Additional proxy headers...

}

}

В данном примере NGINX настроен на listen порта 443 (HTTPS). Запросы, полученные NGINX, передаются на внутренний сервис (your-backend-service) по зашифрованному соединению. Таким образом обеспечивается шифрование соединений между компонентами, даже если они находятся в разных контейнерах или системах.

Remediation:

Для выполнения данного требования необходимо учитывать следующие рекомендации:

1. Use Secure Protocols:

Использовать безопасные протоколы, такие как HTTPS/TLS для веб-соединений, SSH для защищенного доступа к системе или VPN для защищенных сетевых соединений.

2. Encryption Libraries and Tools:

Использовать популярные и проверенные библиотеки и средства шифрования.

3. Certificates and Keys Management:

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

4. Authentication and Authorization:

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

5. Logging and Monitoring:

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

6. Third-Party Services:

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

Additional: