16장. API 끝점 강화

OpenStack은 공용, 내부 관리자 및 개인 API 엔드포인트를 둘 다 제공합니다. 기본적으로 OpenStack 구성 요소는 공개적으로 정의된 엔드포인트를 사용합니다. 적절한 보안 도메인 내에서 API 엔드포인트를 사용하도록 이러한 구성 요소를 구성하는 것이 좋습니다. 내부 관리 엔드포인트에서는 keystone에 대한 추가 액세스를 허용하므로 이를 추가로 격리하는 것이 바람직할 수 있습니다.

서비스는 OpenStack 서비스 카탈로그를 기반으로 각 API 엔드포인트를 선택합니다. 이러한 서비스는 나열된 공용 또는 내부 API 엔드포인트 값을 준수하지 못할 수 있습니다. 이로 인해 내부 관리 트래픽이 외부 API 엔드포인트로 라우팅될 수 있습니다.

ID 서비스 카탈로그는 내부 URL을 인식해야 합니다. 이 기능은 기본적으로 사용되지 않지만 구성을 통해 사용할 수 있습니다. 또한 이 동작이 기본값이 되면 예상 변경 사항과 전달될 수 있어야 합니다.

액세스 수준이 다르면 네트워크 수준에서 구성된 엔드포인트를 격리하는 것이 좋습니다. 관리 엔드포인트는 클라우드 관리자가 액세스하기 위한 것입니다. 내부 또는 공용 엔드포인트에서는 사용할 수 없는 keystone 작업에 대한 높은 액세스 권한을 제공합니다. 내부 엔드포인트는 클라우드 내부(예: OpenStack 서비스)를 사용하기 위한 것이며, 일반적으로 배포 네트워크 외부에서는 액세스할 수 없습니다. 공용 엔드포인트는 TLS를 활성화하고 클라우드 사용자가 작동할 배포 외부에서 액세스할 수 있는 유일한 API 엔드포인트입니다.

엔드포인트의 내부 URL 등록은 director가 자동화합니다. 자세한 내용은 https://github.com/openstack/tripleo-heat-templates/blob/a7857d6dfcc875eb2bc611dd9334104c18fe8ac6/network/endpoints/build_endpoint_map.py 의 내용을 참조하십시오.

일부 서비스에서 특정 API 끝점을 사용하도록 할 수 있습니다. 따라서 적절한 내부 API 엔드포인트에 액세스하도록 다른 서비스의 API를 연결하는 모든 OpenStack 서비스를 명시적으로 구성해야 합니다.

각 프로젝트에 대상 API 엔드포인트를 정의하는 일관되지 않은 방법이 있을 수 있습니다. 향후 OpenStack 릴리스에서는 ID 서비스 카탈로그를 일관되게 사용하여 이러한 불일치를 해결하려고 합니다.

OpenStack의 대부분의 API 엔드포인트 및 기타 HTTP 서비스는 Python Paste Deploy 라이브러리를 사용합니다. 보안 관점에서 이 라이브러리를 사용하면 애플리케이션 구성을 통해 요청 필터 파이프라인을 조작할 수 있습니다. 이 체인의 각 요소를 미들웨어라고 합니다. 파이프라인에서 필터 순서를 변경하거나 추가 미들웨어를 추가하면 예기치 않은 보안에 영향을 미칠 수 있습니다.

일반적으로 구현자는 미들웨어를 추가하여 OpenStack의 기본 기능을 확장합니다. 비표준 소프트웨어 구성 요소를 HTTP 요청 파이프라인에 추가하여 발생할 수 있는 노출에 대해 신중하게 고려하십시오.

API 엔드포인트 프로세스, 특히 공용 보안 도메인에 있는 프로세스를 격리해야 합니다. 배포를 허용하는 경우 격리를 높이기 위해 API 엔드포인트를 별도의 호스트에 배포해야 합니다.

Linux는 네임스페이스를 사용하여 프로세스를 독립 도메인에 할당합니다. 본 가이드의 다른 부분에서는 시스템 구분을 자세히 다룹니다.

API 엔드포인트는 일반적으로 여러 보안 영역에 걸쳐 있으므로 API 프로세스 분리에 특히 주의해야 합니다. 예를 들어 네트워크 설계 수준에서는 지정된 시스템에 대한 액세스만 제한할 수 있습니다. 자세한 내용은 보안 영역에 대한 지침을 참조하십시오.

신중하게 모델링하면 네트워크 ACL 및 IDS 기술을 사용하여 네트워크 서비스 간에 명시적인 지점 간 통신을 적용할 수 있습니다. 중요한 교차 도메인 서비스로서 이러한 유형의 명시적 적용은 OpenStack의 메시지 대기열 서비스에 잘 작동합니다.

정책을 적용하기 위해 서비스, 호스트 기반 방화벽(예: iptables), 로컬 정책(SELinux) 및 선택적으로 글로벌 네트워크 정책을 구성할 수 있습니다.

시스템의 다른 프로세스와 API 엔드포인트 프로세스를 서로 분리해야 합니다. 이러한 프로세스의 구성은 DAC(임의적 액세스 제어) 및 MAC(강제적 액세스 제어)를 통해 해당 프로세스로 제한되어야 합니다. 이러한 향상된 액세스 제어의 목표는 API 엔드포인트 보안 침해를 포함하는 데 도움이 되는 것입니다.

속도 제한은 네트워크 기반 애플리케이션에서 수신한 이벤트 빈도를 제어하는 수단입니다. 강력한 속도 제한이 없으면 애플리케이션이 다양한 서비스 거부 공격에 취약해질 수 있습니다. 이는 특히 비슷한 요청 유형 및 작업의 높은 빈도를 허용하도록 설계된 API에 특히 해당합니다.

모든 엔드포인트(특히 공용)에서 물리적 네트워크 설계, 속도 제한 프록시 또는 웹 애플리케이션 방화벽을 사용하는 추가적인 보호 계층을 제공하는 것이 좋습니다.

운영자가 속도 제한 기능을 구성하고 구현할 때 OpenStack 클라우드 내에서 사용자 및 서비스의 개별 성능 요구 사항을 신중하게 계획하고 구현하는 것이 중요합니다.

Red Hat OpenStack Platform 배포의 경우 모든 서비스가 부하 분산 프록시 뒤에 배치됩니다.