[AZ-204] Azure Aut & API Management

게시 2024/12/30

8 분읽는 시간

Azure 사용자 인증

Microsoft ID 플랫폼 탐색

서비스에서 사용되는 ID 및 엑세스 등의 기능을 Microsoft Entra ID로 위임하는 방식 개발자가 직접 ID 및 보안공간의 기술에 대해 고민하지 않고 Microsoft ID 플랫폼에 이를 위임하는 방식이다. 이는 OAuth2.0 권한 부여 프로토콜을 통해 구현되어 있다.

Azure portal에 앱을 등록하는 경우 이러한 기능을 사용하기 위해 두가지 테넌트 type이 존재한다.

단일 테넌트 : 해당 테넌트에만 엑세스 가능
다중 테넌트 : 다른 테넌트에도 엑세스 가능

Application 개체

Microsoft Entra ID 테넌트내에 생성되는 독특한 개체로 전역적이고 고유한 정의이다. 이 Application 개체는 다른 테넌트를 관리하며 템플릿 역할도 제공한다. 그 외에 토큰 발급, 리소스 엑세스 등을 수행하여 전체적으로 Entra ID 환경 내의 핵심 구성 요소이다.

서비스 주체 개체

Entra ID로 보호되는 개체에 엑세스 하기 위해서는 엔티티가 보안 주체로 표시되어야한다. 이러한 보안 주체는 EntraID에서 정의 되는데 주로 관리 ID, 어플리케이션(테넌트 관리), credentials(레거시) 등이 사용된다.

권한의 유형

Microsoft ID에 권한을 위임하고 위임된 엑세스와 앱 전용 엑세스 권한이라는 두가지 형식을 지원하는데 위임된 엑세스는 사용자 또는 관리자가 앱을 실행하고 역할을 받는 방식이며, 앱 전용 엑세스 권한은 사용자 없이 백그라운드에서 실행하는 옵션이다. 오직 관리자만 동의 할 수 있다.

Q. Entra ID를 사용하여 인증을 부여할려고 한다. 만약 앱 등록이 제거된다면 사용자 정의 역할도 제거되어야 한다면 어떤식으로 하면 좋을까?

정답: Application Manifest 같은 곳에 appRoles 속성을 설정하여 역할 정보를 정의한다. 이러한 정보는 App이 삭제될 때 같이 제거된다.

OAuth 2.0 On-Behalf-Of

OAuth 2.0 OBO는 AP가 사용자를 대신하여 리소스에 대한 토큰을 요청하는 방식으로 다단계 AP, API 호출 체인에서 주로 사용된다.

주로 사용자가 App1에 로그인하여 엑세스 토큰을 받은 뒤, App1이 요청을 처리할 때 다른 App2에 App1의 신원을 기반으로 새로운 엑세스 토큰을 요청한다. 이를 통해 App1은 App2에게 있어 원하는 응답을 받았고 이를 가공해 사용자에게 결과를 리턴한다.

OBO 특징 사용자 대신 권한을 위임함으로써 다단계 인증 흐름을 지원한다. 즉 사용자는 App1의 권한을 가지고 그 뒤는 권한을 가지고 있지 않기에 보안성이 증가한다. 또한 특정 API의 토큰에만 제한을 둠으로써 원하지 않은 사용자의 접근을 차단한다.

Azure App Configuration

AP구성 및 기능 플래그들을 중앙에서 관리하는 서비스(JSON, Key-Vaule), 기능 플래그 등을 활용해 단계적 배포, 테스트 등을 구현 가능

Key Vault와 연동하여 민감한 정보 보호가 가능며 다양한 인증 방식을 통해 접근이 가능하다.

Azure Entra ID : Entra ID에서 엑세스 토큰을 요청하고 이를 통해 접근하는 방법
관리 ID : App configuration에서 관리 ID 사용 설정 후 역할 할당에서 대상 지정
OAut 2.0을 사용한 수동 토큰 요청 : _https://.azconfig.io_에 수동으로 엑세스 토큰을 요청한다.

API Management

API 게이트웨이, 관리 평면, 개발자 포털로 이루어져 하나이상의 API들로 구성된 완전 관리 API Management 프로그램

API Management는 시스템 그룹이 존재하는데 관리자, 개발자, 게스트로 이루어져 있으며 사용자는 추가적인 그룹을 만들 수 있다.

또한 API 요청에 있어 정책을 사용하여 순차석으로 실행되는 명령문의 컬렉션을 생성 가능하다. (ex: XML -> JSON) 또한 사용자의 요구에 맞추어 전역 API, 특정 API의 작업이 가능하다.

API Gateway

서비스에는 몇가지 엔드포인트가 존재한다. 하지만 이런 엔드포인트를 그대로 노출시키는 것은 코드의 복잡성과 추적성에 있어 비효율적이다. 이를 해결하기위해 API Management Gateway로써 클라이언트와 서비스 사이에 배치되어 요청을 라우팅하는 (역방향 프록시) 로 사용된다. HTTPS 통신을 할때 클라이언트 인증서를 사용학거나 혼잡성 제어 기능도 제공한다. -> 디자인 패턴의 완성

API Management는 관리형과 자체 호스팅 모두 지원하는데 관리형은 Azure에 배포된 기본 게이트웨이의 구성 요소로 관리형 게이트웨이를 허용하면 모든 API 트래픽이 Azure로 통과되는 형식이다. 자체 호스팅은 게이트웨이의 컨테이너화 버전으로 하이브리드 및 다중 클라우드 시나리오에 주로 사용된다.

API 보호

구독 Key나 인증된 CA를 통해 인증과정을 거쳐 API Magament를 보호 할 수 있다.

Azure, Azure 204