aws-systems-manager

1 개의 포스트

figma

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 피싱 대응까지 함께 설계해야 한다.