Назови случаи, когда открываешь TCP порты

Открытие TCP портов: основные случаи и соображения безопасности

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

1. Внешнее обслуживание публичных сервисов

Это самый очевидный случай. Порт открывается на границе сети (в firewall или на load balancer) для предоставления услуг конечным пользователям.

• Web-сервисы (HTTP/HTTPS): Порт 443/TCP для HTTPS и порт 80/TCP для HTTP (часто с обязательным переходом на HTTPS).

  # Пример конфигурации Nginx, открывающего порт 443
  server {
      listen 443 ssl;
      server_name example.com;
      ssl_certificate /etc/ssl/certs/example.crt;
      ssl_certificate_key /etc/ssl/keys/example.key;
      ...
  }
  

• API и микросервисы: Публичные REST или GraphQL API, доступные для клиентов или партнеров.
• Сервисы передачи данных: Например, SFTP (SSH File Transfer Protocol) на порту 22/TCP.

2. Связь между внутренними компонентами системы

В распределенных системах компоненты должны взаимодействовать друг с другом внутри доверенной среды (например, внутри одного VPC или приватной сети).

• Связь между сервисами в микросервисной архитектуре: Сервис orders открывает порт (например, 8080/TCP) для приема запросов от сервиса payments.

  # Пример аннотации в Kubernetes для Service
  apiVersion: v1
  kind: Service
  metadata:
    name: orders-service
  spec:
    ports:
      - port: 8080          # Порт, открытый Service для внутреннего кластера
        targetPort: 8080    # Порт, на котором работает контейнер
    selector:
      app: orders
  

• Доступ к базам данных: Сервер приложения открывает порт для подключения к БД. Например, PostgreSQL использует 5432/TCP. Ключевой момент: этот порт почти никогда не открывают напрямую из интернета. Доступ ограничивают подсетью или security groups.

  # Пример правила Security Group в AWS (Terraform)
  resource "aws_security_group_rule" "app_to_db" {
    type              = "ingress"
    from_port         = 5432
    to_port           = 5432
    protocol          = "tcp"
    source_security_group_id = aws_security_group.app.id # Только от app SG
    security_group_id = aws_security_group.db.id
  }
  

• Обмен сообщениями (Message Brokers): Сервисы подключаются к RabbitMQ (5672/TCP) или Kafka для обмена событиями.

3. Административный доступ и управление

• SSH для управления серверами: Порт 22/TCP для доступа к Linux-серверам. Золотой стандарт: доступ только через VPN или bastion host (jump server), а не напрямую из интернета.
• Доступ к интерфейсам управления: Порты для Kubernetes API (6443/TCP), Consul (8500/TCP), или интерфейсам мониторинга (например, Prometheus). Они всегда защищены аутентификацией и находятся в приватной сети.

4. Специализированные протоколы и интеграции

• SMTP (25, 587/TCP) для отправки почты с почтовых серверов.
• Порты для TLS-терминирования или проксирования: Когда на одном хосте (например, Traefik или nginx) терминируется TLS, и он передает трафик на внутренние сервисы.

5. Временное открытие для диагностики или миграции

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

• Перенос данных: Открытие порта БД для подключения со стороны временного миграционного скрипта.
• Диагностика сетевых проблем: Временное разрешение telnet или nc для проверки доступности сервиса из определенной сети. Используется строго по необходимости и с аудитом.

Критические принципы и меры безопасности

При открытии любого порта я всегда применяю следующие практики:

• Принцип минимальных разрешений (Least Privilege): Открывать порт только для конкретных IP-адресов, подсетей или security groups, а не для 0.0.0.0/0 (всех).
• Обязательное использование брандмауэров: Контроль на уровне host (например, iptables/nftables) и на уровне network (AWS Security Groups, GCP Firewall Rules).

  # Пример правила iptables, разрешающего доступ только из внутренней сети 10.0.1.0/24
  iptables -A INPUT -p tcp --dport 5432 -s 10.0.1.0/24 -j ACCEPT
  iptables -A INPUT -p tcp --dport 5432 -j DROP
  

• Шифрование трафика: Для любого публичного и большинства внутренних сервисов обязательным является использование TLS. Внутренний трафик также шифруется (например, с помощью mTLS в service mesh).
• Регулярный аудит и review: Все открытые порты должны быть задокументированы и периодически пересматриваться на предмет необходимости. Используются инструменты сканирования (например, nmap внутри доверенной сети) для обнаружения неожиданно открытых портов.

  # Пример аудита открытых портов на хосте
  netstat -tulpn | grep LISTEN
  # или с помощью ss
  ss -tln
  

• Сегментация сети (Network Segmentation): Использование разных подсетей/VPC для разных уровней сервисов (публичные, приватные, административные) и контроль трафика между ними.

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