OCI API Gateway 및 OpenID Connect를 사용하여 웹 애플리케이션 보호
레거시 웹 애플리케이션을 최신 ID 제공자와 통합하려면 일반적으로 레거시 애플리케이션 코드를 수정하고 사용자 인터페이스를 변경해야 합니다. 새 커스텀 개발에 시간과 리소스를 소비하는 대신 인증 흐름 대신 업무 논리에 집중할 수 있는 구조에 투자합니다.
일부 레거시 애플리케이션은 OpenID Connect를 직접 지원하지 않습니다. 클라우드로 이전하면서 Oracle Cloud Infrastructure(OCI) API 게이트웨이를 네트워크 액세스 포인트로 사용하여 사용자, ID 제공자 및 애플리케이션과의 인증을 조정할 수 있습니다. OCI API Gateway는 모든 애플리케이션이 OpenID Connect 흐름을 직접 추가하도록 요구하는 대신 네트워크에서 표준화된 방식으로 액세스를 적용할 수 있습니다. 개발자는 OCI API 게이트웨이를 사용하여 레거시 애플리케이션을 현대화하는 동시에 최신 애플리케이션을 개선할 수 있습니다.
구조
OCI API 게이트웨이는 API 엔드포인트 및 웹 애플리케이션을 보호하는 데 사용할 수 있는 OCI의 서버리스 완전 관리형 서비스입니다. OCI API 게이트웨이는 속도 제한, 권한 부여 적용, 동적 라우팅, SSL 적용 등과 같은 보안 기능을 제공합니다. OCI API 게이트웨이는 OpenID 인증 지원이 필요한 레거시 웹 애플리케이션을 보호하는 데 활용할 수 있습니다. OCI API 게이트웨이는 OCI 전용 서브넷에서 호스팅되는 웹 애플리케이션에 대한 중앙 집중식 보안 모듈 역할을 할 수 있습니다. OCI API 게이트웨이는 ID 제공자의 영향을 받지 않으며, Okta, Google, Amazon, Auth0 등 지원되는 모든 OAuth 2.0 제공자와 통합되어 몇 가지 이름을 지정할 수 있습니다.
OpenID Connect 프로토콜은 OAuth 2.0 프로토콜 위에 있는 간단한 ID 계층입니다. OpenID Connect를 사용하면 브라우저, 모바일 애플리케이션, 데스크톱 클라이언트 등 다양한 유형의 애플리케이션이 안전하고 중앙 집중식이며 표준화된 방식으로 인증 및 ID 관리를 지원할 수 있습니다. OpenID Connect 프로토콜을 활용하는 앱은 ID 제공자를 사용하여 인증 프로세스를 안전하게 처리하고 사용자 ID를 확인합니다. OpenID Connect는 Oracle Cloud Infrastructure Identity and Access Management와 같은 ID 제공자를 통해 사용자 관리를 중앙 집중화함으로써 서로 다른 애플리케이션에 대한 SSO(Single Sign On)를 지원합니다.
OCI API 게이트웨이는 네트워크 액세스 포인트 역할을 하여 사용자, ID 제공자 및 애플리케이션과의 인증을 조정합니다. 애플리케이션과 클라이언트 간에 OCI API 게이트웨이를 배치하면 OCI API 게이트웨이가 요청을 가로채고 OpenID Connect 권한 부여 플로우를 처리할 수 있습니다.
다음 다이어그램은 이 참조 아키텍처를 보여줍니다.
secure-web-applications-oci-api-gateway-open-id-architecture.zip
다음 다이어그램은 초기 권한 부여에 대한 인증 플로우를 보여줍니다.
secure-web-applications-oci-api-gateway-open-id-data-flow.zip
- 클라이언트 애플리케이션이 OCI API 게이트웨이를 통해 백엔드 서비스에 대한 액세스를 요청합니다.
- OCI API 게이트웨이는 클라이언트를 ID 제공자로 지정합니다.
- 클라이언트가 ID 제공자를 사용하여 인증합니다. 성공적으로 인증되면 클라이언트는 권한 부여를 제공하는 토큰을 받습니다.
- ID 제공자는 액세스 토큰을 사용하여 클라이언트를 OCI API 게이트웨이로 재지정합니다.
- OCI API 게이트웨이는 ID 제공자와 함께 액세스 토큰을 검증합니다.
- 토큰 검증을 성공하면 OCI API 게이트웨이가 적절한 백엔드 서비스로 라우팅되고 이행된 응답이 클라이언트에 반환됩니다.
클라이언트에 이미 권한이 부여된 경우 플로우는 다음 다이어그램과 유사합니다.
secure-web-applications-oci-api-gateway-open-id-data-flow-authorized.zip
- 토큰을 얻은 후 브라우저는 동일한 응용 프로그램에 대한 후속 요청에 대한 토큰을 캐시합니다.
- OCI API 게이트웨이는 ID 제공자와 토큰을 검증하여 클라이언트가 백엔드 서비스에 액세스할 수 있는지 확인합니다.
- 클라이언트에 권한이 부여된 경우 OCI API Gateway는 적절한 백엔드 서비스로 라우팅되고 이행된 응답을 클라이언트에 반환합니다.
아키텍처에는 다음과 같은 구성 요소가 있습니다.
- 지역
Oracle Cloud Infrastructure 리전은 가용성 도메인이라는 하나 이상의 데이터 센터를 포함하는 지역화된 지리적 영역입니다. 지역은 다른 지역과 독립적이며 방대한 거리로 구분할 수 있습니다(국가 또는 대륙).
- 가용성 도메인
가용성 도메인은 한 지역 내의 독립형 데이터 센터입니다. 각 가용성 도메인의 물리적 리소스는 다른 가용성 도메인의 리소스와 격리되어 내결함성을 제공합니다. 가용성 도메인은 전원, 냉각 또는 내부 가용성 도메인 네트워크와 같은 인프라를 공유하지 않습니다. 따라서 특정 가용성 도메인에서 실패할 경우 해당 지역의 다른 가용성 도메인에 영향을 주지 않습니다.
- 결함 도메인
장애 도메인은 가용성 도메인 내 하드웨어와 인프라의 그룹입니다. 가용성 도메인마다 별도의 전원 및 하드웨어가 있는 장애 도메인 3개가 있습니다. 여러 장애 도메인에 리소스를 분배할 때 응용 프로그램은 물리적 서버 실패, 시스템 유지 관리 및 결함 도메인 내의 전원 실패를 허용할 수 있습니다.
- VCN(가상 클라우드 네트워크) 및 서브넷
VCN은 Oracle Cloud Infrastructure 지역에서 설정한 커스터마이징 가능한 소프트웨어 정의 네트워크입니다. 기존 데이터 센터 네트워크와 마찬가지로 VCN은 사용자가 네트워크 환경을 완전히 제어할 수 있도록 합니다. VCN에는 VCN을 생성한 후 변경할 수 있는 겹치지 않는 여러 CIDR 블록이 있을 수 있습니다. VCN을 서브넷으로 분할할 수 있습니다. 서브넷은 지역 또는 가용성 도메인으로 범위가 지정될 수 있습니다. 각 서브넷은 VCN의 다른 서브넷과 겹치지 않는 연속된 주소 범위로 구성됩니다. 서브넷 생성 후 서브넷의 크기를 변경할 수 있습니다. 서브넷은 공용 또는 전용일 수 있습니다.
- API 게이트웨이
Oracle API Gateway를 사용하면 네트워크 내에서 액세스할 수 있고 필요한 경우 공용 인터넷에 노출할 수 있는 전용 끝점이 있는 API를 게시할 수 있습니다. 끝점은 API 검증, 요청 및 응답 변환, CORS, 인증 및 권한 부여, 요청 제한 등을 지원합니다.
- IAM(ID 및 액세스) 관리
Oracle Cloud Infrastructure Identity and Access Management(IAM)는 Oracle Cloud Infrastructure(OCI) 및 Oracle Cloud Applications의 액세스 제어 플레인입니다. IAM API 및 사용자 인터페이스를 통해 ID 도메인 및 ID 도메인 내의 리소스를 관리할 수 있습니다. 각 OCI IAM ID 도메인은 독립형 ID 및 액세스 관리 솔루션 또는 다른 사용자 모집단을 나타냅니다.
- FastConnect
Oracle Cloud Infrastructure FastConnect는 데이터 센터 및 Oracle Cloud Infrastructure 간 전용 개인 연결을 생성할 수 있는 쉬운 방법을 제공합니다. FastConnect는 인터넷 기반 연결과 비교할 때 더 높은 대역폭 옵션과 보다 안정적인 네트워킹 환경을 제공합니다.
- OCI 및 Azure 상호 연결
Oracle Cloud 및 Microsoft Azure Interconnect는 Oracle 최초의 멀티클라우드 오퍼링입니다. 전 세계 특정 Azure와 Oracle Cloud Infrastructure(OCI) 데이터 센터 간에 직접 네트워크 연결을 제공합니다. Azure 관리자와 개발자는 전용 링크를 생성하거나 공용 인터넷을 통해 애플리케이션 트래픽을 전송하지 않고도 OCI에서 실행되는 애플리케이션과 서비스에 애플리케이션을 연결할 수 있습니다.
권장 사항
- OCI API 게이트웨이
OCI API 게이트웨이를 활용하여 REST API를 노출하고 웹 애플리케이션에 대한 Single Sign-On 지원을 활성화할 수 있습니다. OCI API 게이트웨이를 중앙 집중식 보안 모듈로 지정하여 보안 구현을 OCI API 게이트웨이로 오프로드할 수도 있습니다. 이를 통해 구현, 유지 관리 및 복잡성과 관련된 비용을 최소화할 수 있습니다.
고려 사항
이 참조 구조를 배치할 때는 다음을 고려하십시오.
- 교차 사이트 요청 위조(CSRF) 보호
공격자는 브라우저 쿠키의 존재를 활용하여 사용자가 의도하지 않은 명령을 웹 애플리케이션(예: OCI API 게이트웨이)에 제출하도록 하여 CSRF 공격을 마운트할 수 있습니다. 응용 프로그램에서 브라우저 쿠키가 존재하여 사용자가 이미 성공적으로 인증되었다고 판단하면 응용 프로그램이 잠재적으로 손상을 주는 결과로 명령을 실행합니다.
OAuth 2.0 introspection endpoint유형의 검증 정책과OAuth 2.0유형의 검증 실패 정책을 정의할 때 OCI API Gateway가 OpenID Connect 권한 부여 플로우를 사용하여 얻은 새 JWT 토큰을 저장하는 방법을 지정합니다.새 JWT 토큰을 세션 쿠키에 저장하려면
Use cookies for session을 선택합니다. 잠재적 CSRF 공격을 방지하기 위해 OCI API Gateway가 토큰을 세션 쿠키에 저장할 때X-CSRF-TOKEN응답 헤더에 CSRF 토큰도 반환합니다. OCI API 게이트웨이에 대한 후속 요청(GET 요청의 부분)은 세션 쿠키의 JWT 토큰 외에도X-CSRF-TOKEN요청 헤더에 CSRF 토큰을 포함해야 합니다. - CORS(Cross-Origin Resource Sharing)
웹 브라우저에서 OCI API 게이트웨이를 통해 요청이 재지정되므로 애플리케이션에서 사용되는 웹 애플리케이션 및 기타 REST API가 CORS를 지원해야 할 수 있습니다.