aws2026년 2월 3일

Amazon Web Services": | Amazon (새 탭에서 열림)

AWS IAM Identity Center가 멀티 리전 복제 기능을 지원함에 따라 외부 ID 공급자(IdP)를 사용하는 조직의 가동 중지 리스크를 줄이고 전 세계적인 서비스 가용성을 확보할 수 있게 되었습니다. 이제 기본 리전의 ID 정보와 권한 세트 등을 추가 리전에 복제하여, 기본 리전 장애 시에도 추가 리전의 액세스 포털을 통해 중단 없는 AWS 계정 접속이 가능합니다. 또한 사용자나 데이터 세트와 가까운 리전에 애플리케이션을 배치함으로써 성능 최적화와 데이터 레지던시 요구 사항을 동시에 충족할 수 있습니다. ### 서비스 복원력 및 애플리케이션 성능 향상 * 기본 리전의 조직 인스턴스에 연결된 인력 ID, 권한 세트, 메타데이터를 사용자가 지정한 추가 리전으로 복제하여 고가용성을 확보합니다. * 기본 리전에서 서비스 중단이 발생하더라도, 이미 프로비저닝된 권한을 바탕으로 추가 리전의 활성 AWS 액세스 포털 엔드포인트를 통해 계정에 접속할 수 있습니다. * AWS 관리형 애플리케이션을 데이터와 가까운 지역에 배포하여 사용자 경험을 개선하고, 규정에 따른 데이터 지역 제한 요구 사항을 준수할 수 있습니다. ### 설정 요구 사항 및 멀티 리전 KMS 구성 * 이 기능을 사용하려면 Microsoft Entra ID 또는 Okta와 같은 외부 IdP에 연결된 IAM Identity Center의 **조직 인스턴스**를 사용해야 합니다. * 암호화를 위해 고객 관리형 **멀티 리전 AWS KMS 키**가 필수적이며, 복제하려는 리전에 해당 키를 미리 복제하고 관련 권한을 구성해야 합니다. * 기본 리전 콘솔의 '설정' 메뉴에서 멀티 리전 KMS 키 사용 여부를 확인한 후, 원하는 리전을 선택하여 복제 프로세스를 시작할 수 있습니다. ### 외부 IdP 연동 및 운영 제어 방식 * 멀티 리전 환경을 지원하기 위해서는 외부 IdP(예: Okta 관리 콘솔) 설정에 추가된 리전의 **ACS(Assertion Consumer Service) URL**을 등록해야 합니다. * 사용자가 각 리전의 액세스 포털을 쉽게 찾을 수 있도록 IdP 내에 리전별 북마크 애플리케이션을 생성하는 방식이 권장됩니다. * 모든 중앙 구성 관리(ID 및 권한 관리 등)는 기본 리전에서 수행되며, 추가 리전에서는 애플리케이션 관리 및 세션 취소와 같은 제한된 작업만 가능합니다. * 모든 사용자 작업은 해당 작업이 수행된 리전의 AWS CloudTrail에 기록되어 중앙 집중식 모니터링과 보안 감사가 가능합니다. 비즈니스 연속성(BCP)이 중요한 기업은 이 기능을 활용해 인증 서비스 장애에 대비한 '브레이크 글래스(Break-glass)' 액세스 전략을 강화할 것을 권장합니다. 현재 기본적으로 활성화된 17개의 상업용 AWS 리전에서 추가 비용 없이(KMS 비용 별도) 즉시 도입할 수 있습니다.

oktasamlsingle-sign-onidentity-and-access-management+4

figma2021년 9월 1일

Figma 내부 살펴보기: (새 탭에서 열림)

Figma는 기존의 bastion host와 SSH 중심 접근을 AWS Systems Manager Session Manager 기반의 제로 트러스트 셸 접근 방식으로 전환했다. Okta·AWS SSO·WebAuthn·최소 권한 IAM 역할·단기 자격 증명을 결합해 인증과 권한을 중앙화하고, 세션 기록을 S3에 저장해 감사 가능성을 확보했다. 외부 보안 제품에 대한 의존성을 줄이면서도 기존 사용성을 유지하고 점진적으로 도입하는 것이 핵심 결론이다. ## 기존 Bastion Host 방식의 한계 - 프로덕션 환경 보호를 위해 엔지니어가 bastion host를 거쳐 SSH로 접속하는 방식이 널리 사용된다. - 그러나 bastion host는 공격자가 집중적으로 노리는 중요한 보안 통제 지점이다. - Figma는 규모가 커지면서 다음 문제가 커졌다고 설명한다. - 접근 권한 관리가 복잡해짐 - bastion host 자체의 보안 유지 비용 증가 - 사용자별 접근 추적과 감사의 어려움 - 운영 및 지원에 필요한 반복 작업 증가 ## 설계 목표 Figma 보안팀은 새로운 셸 접근 시스템을 다음 원칙에 맞춰 설계했다. - **원활한 사용자 경험** - 엔지니어가 보안을 우회하지 않고도 쉽게 사용할 수 있어야 한다. - 웹 콘솔과 터미널 CLI를 모두 지원한다. - **제로 트러스트** - 네트워크 내부에 있다는 이유만으로 신뢰하지 않고, 매번 사용자와 요청을 검증한다. - 외부 네트워크에 인스턴스를 노출하지 않는 구조를 지향한다. - **강력한 인증** - SSO를 강제한다. - 피싱에 강한 WebAuthn 기반 MFA와 디바이스 신뢰 검사를 적용한다. - 탈취된 자격 증명의 피해 범위를 줄이기 위해 단기 토큰을 사용한다. - **중앙 집중식 감사** - 사용자가 어떤 시스템에 접속했고 어떤 명령을 실행했는지 추적할 수 있어야 한다. - **운영 부담 최소화** - 구축과 배포가 단순하고 유지보수가 쉬워야 한다. - **점진적·하위 호환 가능한 도입** - 기존 사용 사례를 지원하면서 단계적으로 전환한다. - 갑작스러운 업무 중단이나 사용자 경험의 큰 변화를 피한다. ## 자체 구축을 선택한 이유 - Figma는 초기 검토 과정에서 Okta Advanced Server Access 같은 상용 제품을 평가했다. - 하지만 기존 사용 사례를 유연하게 지원하기 어렵고, 당시 회사 규모에서는 제품을 이용하기 어려운 경우도 있었다. - 외부 서비스 의존성이 핵심 엔지니어링 업무의 가용성 위험과 추가 복잡성을 만들 수 있다는 우려도 있었다. - 이미 AWS 서비스를 광범위하게 사용하고 있었기 때문에 AWS 구성 요소를 조합해 단순한 프로토타입을 만드는 방향을 택했다. ## Session Manager 기반 셸 접근 - AWS Systems Manager의 Session Manager를 사용하면 EC2 및 ECS 인스턴스에 셸 접근을 제공할 수 있다. - 인스턴스에 SSH 포트를 열거나 외부 네트워크에서 직접 접근 가능하게 만들 필요가 없다. - 인스턴스의 에이전트와 사용자의 AWS 콘솔·CLI 사이에 인증되고 암호화된 TLS 연결을 생성한다. - 지원 기능은 다음과 같다. - 명령 실행 - 대화형 셸 - SSH 세션 터널링 - 사람이 AWS SSO로 인증한 뒤 IAM 역할을 Assume하도록 구성해 권한을 중앙 관리할 수 있다. - 네트워크 경계나 bastion host의 보안에 의존하기보다 사용자 인증과 IAM 권한을 중심으로 접근을 통제한다. ## Okta와 AWS SSO를 이용한 인증·권한 관리 - Figma는 Okta를 SSO 제공자로 사용하고 AWS SSO와 연동했다. - 인증 과정에서 디바이스 신뢰와 WebAuthn MFA를 요구한다. - 인증이 끝나면 사용자는 최소 권한으로 제한된 전용 IAM 역할을 Assume한다. - AWS 접근 토큰은 단기 수명으로 발급해 장기 키가 유출됐을 때의 피해 범위를 줄인다. - Okta 그룹을 AWS SSO 그룹과 연동해 IT 팀이 그룹 단위로 접근 권한을 관리할 수 있다. - 사용자는 다음 두 방식으로 Session Manager를 이용할 수 있다. - AWS Systems Manager 콘솔을 통한 웹 기반 접속 - Figma가 제작한 간단한 CLI 도구를 통한 터미널 접속 ## 세션 기록과 감사 - Session Manager는 셸 세션의 transcript를 수집한다. - 기록은 암호화된 S3 버킷으로 전송된다. - 이를 통해 개인별 접속과 실행 작업을 사후 조사할 수 있다. - 중앙화된 로그는 보안 사고 대응, 내부 감사, 권한 오남용 조사에 활용될 수 있다. ## AWS SSO 디바이스 코드 피싱 위험 - AWS SSO의 디바이스 코드 인증은 별도의 피싱 위험을 가진다. - 공격자가 자신의 디바이스 인증 URL을 생성한 뒤 피해자가 해당 URL을 방문해 승인을 수행하도록 속일 수 있다. - 그러면 공격자가 피해자 계정의 액세스 토큰을 획득할 가능성이 있다. - Figma는 사용자가 예상하지 못한 SSO 페이지를 의심하도록 하는 것 외에도 모니터링과 경보를 추가적인 완화책으로 적용했다. ## 도입 시 고려할 점 - Session Manager를 적용하려면 EC2 또는 ECS 인스턴스에 관련 에이전트와 권한 구성이 필요하다. - IAM 정책은 셸 접근에 필요한 최소 권한만 부여하도록 설계해야 한다. - 외부 SSH 포트를 제거하더라도 IAM, SSO, 세션 로그, S3 저장소의 보안을 함께 관리해야 한다. - 기존 SSH 사용 사례와 사용자 업무 흐름을 고려해 웹 콘솔과 CLI를 함께 제공하는 것이 효과적이다. - 인증 우회나 피싱을 전제로 모니터링과 이상 행위 경보를 추가해야 한다. 실용적으로는 AWS 환경에서 bastion host를 새로 확장하기보다 Session Manager, AWS SSO, 최소 권한 IAM, 단기 자격 증명, 암호화된 세션 로그를 조합하는 방식을 우선 검토할 만하다. 다만 제로 트러스트는 특정 제품 도입만으로 완성되지 않으므로 IAM 정책과 로그 접근 권한, SSO 피싱 대응까지 함께 설계해야 한다.

oktaiamzero-trust-securityssh+3

figma2021년 8월 11일

피그마 내부 이야기: 내부 웹 (새 탭에서 열림)

Figma는 내부 웹 애플리케이션을 안전하게 공개하기 위해 AWS Application Load Balancer(ALB), Cognito, Okta, SAML, Lambda, Terraform을 조합한 중앙화된 접근 제어 시스템을 구축했다. 이 시스템은 사내 네트워크를 신뢰하지 않는 제로 트러스트 원칙을 따르면서도, 직원에게 빠르고 일관된 인증 경험을 제공하는 것을 목표로 한다. 또한 권한 관리를 중앙화하고 인프라 구성을 코드로 자동화해 보안팀의 운영 부담을 줄였다. ## 내부 웹 앱 보안의 요구사항 - 배포, 고객 지원 등 내부 웹 도구는 직원 업무에 필수적이지만 사용자 데이터에 접근할 수 있어 높은 보안 수준이 필요하다. - 공격자는 사용자 데이터를 노리기 위해 관리용 백엔드와 내부 애플리케이션을 주요 공격 대상으로 삼는다. - 시스템 설계 시 다음 요구사항을 우선했다. - 빠르고 안정적이며 사용하기 쉬운 인증 - 네트워크 위치만으로 신뢰하지 않는 제로 트러스트 접근 - WebAuthn 같은 최신 인증 기술 활용 - IT·보안팀이 관리하는 중앙화된 권한 부여 - 소규모 보안팀의 운영 부담 최소화 ## 사용한 핵심 기술 - **SAML** - 서비스 간 사용자 신원 정보를 전달하는 인증 프로토콜이다. - 사용자 신원뿐 아니라 그룹과 역할 정보도 assertion에 포함할 수 있다. - Okta와 AWS Cognito를 연결하는 기반으로 사용된다. - **AWS Application Load Balancer** - HTTP/HTTPS 요청을 받아 규칙에 따라 내부 인프라로 전달하는 관리형 리버스 프록시다. - 애플리케이션 앞단에서 사용자 인증을 수행할 수 있다. - **AWS Cognito** - 사용자 인증 및 관리 API를 제공한다. - SAML과 같은 외부 연합 로그인 기술과 통합할 수 있다. - **AWS Lambda** - 특정 이벤트나 조건에 따라 코드를 실행하는 서버리스 컴퓨팅 구성요소다. - **Terraform** - AWS와 Okta 설정을 코드로 관리한다. - 인증 인프라를 검토·자동화·재사용할 수 있게 해준다. ## ALB와 Okta를 이용한 인증 구조 - Figma는 클라우드 인프라에 AWS를, 직원 인증·권한 관리에 Okta를 사용한다. - ALB는 일반적으로 OIDC 인증을 구성할 수 있지만, Okta의 OIDC 지원 비용 문제로 다른 방식을 검토했다. - 대안으로 **ALB + Cognito 사용자 풀 + Okta SAML** 조합을 사용했다. - Cognito가 SAML 기반 Okta 로그인과 ALB 사이를 연결하므로, ALB가 인증된 트래픽만 내부 애플리케이션으로 전달할 수 있다. - 각 내부 앱마다 Okta에 SAML 애플리케이션을 만들고, 해당 앱과 연결된 Cognito Identity Provider를 구성한다. ## Terraform을 통한 표준화와 자동화 - Figma는 ALB와 Cognito를 올바른 설정으로 생성할 수 있도록 Terraform 모듈을 직접 만들었다. - 인프라 엔지니어는 모듈을 사용해 Okta 인증이 적용된 ALB를 빠르게 배포할 수 있다. - 인증 구성을 수작업으로 반복하지 않고 코드로 관리하므로 다음 효과가 있다. - 설정의 일관성 확보 - 변경 사항 검토 가능 - 여러 내부 앱에 동일한 보안 패턴 재사용 - 운영 및 유지보수 부담 감소 ## Cognito 사용자 풀 구성 - Cognito User Pool에서는 일반 사용자의 직접 회원가입을 허용하지 않는다. - 사용자는 Okta에서 인증되어야 하며, Cognito는 Okta용 SAML Identity Provider와 연결된다. - `email`과 `profile` 같은 속성 매핑을 설정해 Okta의 사용자 정보가 인증 과정에서 전달되도록 한다. - 결과적으로 내부 앱은 각자 복잡한 인증 로직을 구현하지 않고도, ALB 앞단에서 중앙화된 인증을 적용할 수 있다. ## 확장 방향 - 글에서는 기본 인증 구조 외에도 다음 기능 확장을 다룬다. - Okta Groups를 활용한 세밀한 권한 제어 - 엔지니어를 위한 CLI 인증 - 외부 게스트의 안전한 접근 허용 - 공통 인증 계층을 기반으로 웹 브라우저뿐 아니라 명령줄 도구와 제한된 외부 사용자 접근까지 동일한 보안 원칙으로 확장하려는 접근이다. 실무에서는 내부 앱마다 인증 기능을 따로 구현하기보다, ALB 같은 공통 진입점과 중앙 IdP, Terraform 모듈을 결합하는 방식이 효과적이다. 특히 네트워크 위치를 신뢰 기준으로 삼지 않고, 강력한 사용자 인증과 중앙화된 그룹·권한 관리를 적용하는 것이 중요하다.

oktazero-trustaws-lambdaterraform+4