전용 호스트 인스턴스를 사용하여 클라이언트와 애플리케이션 또는 서비스 간의 요청을 조정하여 애플리케이션 및 서비스를 보호합니다. 브로커는 요청의 유효성을 검사하고 삭제하며, 추가 보안 계층을 제공하고 시스템의 공격 노출 영역을 제한할 수 있습니다.
컨텍스트 및 문제점
클라우드 서비스는 클라이언트 애플리케이션이 API를 호출할 수 있도록 하는 엔드포인트를 노출합니다. API를 구현하는 데 사용되는 코드는 인증, 권한 부여, 매개 변수 유효성 검사 및 일부 또는 모든 요청 처리를 포함하지만 제한되지 않는 여러 작업을 트리거하거나 수행합니다. API 코드는 클라이언트를 대신하여 스토리지 및 기타 서비스에 액세스할 가능성이 높습니다.
악의적인 사용자가 시스템을 손상시키고 애플리케이션의 호스팅 환경에 액세스할 수 있는 경우 해당 보안 메커니즘과 데이터 및 기타 서비스에 대한 액세스가 노출됩니다. 결과적으로 악의적인 사용자는 자격 증명, 스토리지 키, 중요한 정보 및 기타 서비스에 무제한으로 액세스할 수 있습니다.
솔루션
이 문제에 대한 한 가지 해결 방법은 요청을 처리하고 스토리지에 액세스하는 코드에서 퍼블릭 엔드포인트를 구현하는 코드를 분리하는 것입니다. 외관 또는 클라이언트와 상호 작용하는 전용 작업을 사용하여 분리한 다음, 분리된 인터페이스를 통해 요청을 처리하는 호스트 또는 태스크에 요청을 전달하는 방식으로 분리할 수 있습니다. 그림에 이 패턴의 대략적인 개요가 나와 있습니다.
게이트키퍼 패턴을 사용하여 스토리지를 보호하거나 보다 포괄적인 외관으로 사용하여 애플리케이션의 모든 기능을 보호할 수 있습니다. 중요한 요인은 다음과 같습니다.
- 제어된 유효성 검사. 게이트키퍼는 모든 요청의 유효성을 검사하고 유효성 검사 요구 사항을 충족하지 않는 요청을 거부합니다.
- 제한된 위험 및 노출. 게이트 키퍼는 신뢰할 수 있는 호스트가 스토리지 및 서비스에 액세스하는 데 사용하는 자격 증명 또는 키에 액세스하지 않습니다. 게이트 키퍼가 손상되면 공격자가 이러한 자격 증명 또는 키에 액세스하지 않습니다.
- 적절한 보안. 게이트 키퍼는 나머지 애플리케이션이 스토리지 및 서비스 액세스에 요구되는 완전 신뢰 모드에서 실행되는 동안 제한된 권한 모드에서 실행됩니다. 게이트 키퍼가 손상되면 애플리케이션 서비스 또는 데이터에 직접 액세스할 수 없습니다.
이 패턴은 일반적인 네트워크 토폴로지의 방화벽과 같은 역할을 합니다. 이를 통해 게이트 키퍼가 요청을 검사하고, 필요한 작업을 수행하는 신뢰할 수 있는 호스트에 요청을 전달할지 여부를 결정할 수 있습니다. 이 결정에는 일반적으로 요청 콘텐츠를 신뢰할 수 있는 호스트에 전달하기 전에 유효성을 검사하고 정리하기 위해 게이트 키퍼가 필요합니다.
문제 및 고려 사항
이 패턴을 구현할 방법을 결정할 때 다음 사항을 고려하세요.
- 신뢰할 수 있는 호스트가 게이트키퍼에서만 사용되는 내부 또는 보호된 엔드포인트만 노출하는지 확인합니다. 신뢰할 수 있는 호스트는 외부 엔드포인트 또는 인터페이스를 노출해서는 안 됩니다.
- 게이트키퍼는 제한된 권한 모드에서 실행되어야 하며, 일반적으로 게이트키퍼와 신뢰할 수 있는 호스트를 별도의 호스트된 서비스 또는 가상 머신에서 실행해야 합니다.
- 게이트키퍼는 애플리케이션 또는 서비스와 관련된 처리를 수행하거나 어떠한 데이터에도 액세스해서는 안 됩니다. 순수하게 유효성을 검사하고 요청을 정리하는 기능만 합니다. 신뢰할 수 있는 호스트는 추가 요청 유효성 검사를 수행해야 하지만 게이트키퍼는 핵심 유효성 검사를 수행해야 합니다.
- 가능한 경우 게이트키퍼와 신뢰할 수 있는 호스트 또는 작업 간에 보안 통신 채널(HTTPS, SSL 또는 TLS)을 사용합니다. 그러나 일부 호스팅 환경은 내부 엔드포인트에 HTTPS를 지원하지 않습니다.
- 게이트키퍼 패턴을 구현하기 위해 추가 계층을 추가하면 필요한 추가 처리 및 네트워크 통신으로 인해 성능에 영향을 줄 수 있습니다.
- 게이트 키퍼 인스턴스는 단일 실패 지점일 수 있습니다. 오류의 영향을 최소화하려면 중복 인스턴스를 배포하고 자동 크기 조정 메커니즘을 사용하여 가용성을 기본 용량을 보장하는 것이 좋습니다.
이 패턴을 사용해야 하는 경우
이 패턴은 다음과 같은 애플리케이션에 유용합니다.
- 중요한 정보 처리
- 악의적인 공격으로부터 높은 수준의 보호가 필요한 서비스 노출
- 중단될 수 없는 중요 업무용 작업을 수행합니다.
- 요청 유효성 검사를 기본 작업과 별도로 수행하거나 이 유효성 검사를 중앙 집중화하여 기본 테넌트 및 관리를 간소화해야 합니다.
워크로드 디자인
설계자는 게이트키퍼 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 요청 흐름에 게이트웨이를 추가하면 웹 애플리케이션 방화벽, DDoS 보호, 봇 검색, 요청 조작, 인증 시작 및 권한 부여 검사 같은 보안 기능을 중앙 집중화할 수 있습니다. - SE:06 네트워크 컨트롤 - SE:10 모니터링 및 위협 감지 |
| 성능 효율성은 크기 조정, 데이터, 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족하는 데 도움이 됩니다. | 이 패턴은 노드 수준에서 속도 검사 구현하는 대신 게이트웨이 수준에서 제한을 구현하는 방법입니다. 모든 노드 간에 속도 상태를 조정하는 것은 본질적으로 성능이 없습니다. - PE:03 서비스 선택 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.
예시
클라우드 호스팅 시나리오에서 이 패턴은 애플리케이션의 신뢰할 수 있는 역할 및 서비스에서 게이트키퍼 역할 또는 가상 머신을 분리하여 구현할 수 있습니다. 구현은 중간 통신 메커니즘으로 내부 엔드포인트, 큐 또는 스토리지를 사용할 수 있습니다. 이 그림에서는 내부 엔드포인트를 사용하는 모습을 보여 줍니다.
관련 참고 자료
Valet 키 패턴은 게이트 키퍼 패턴을 구현하는 경우와 관련될 수도 있습니다. 이는 게이트 키퍼와 신뢰할 수 있는 역할 사이에서 통신할 때 리소스에 대한 액세스 사용 권한을 제한하는 키 또는 토큰을 사용하여 보안을 강화하기에 좋은 사례입니다. 패턴은 클라이언트에 특정 리소스 또는 서비스에 대한 제한된 직접 액세스를 제공하는 토큰 또는 키를 사용하는 방법을 설명합니다.