saml

7 개의 포스트

cloudflare

신원 인식형 분석으로 통제 불능 AI 행동 포착하기 (새 탭에서 열림)

AI 사용량의 이상 징후를 파악하려면 요청마다 검증된 사용자·에이전트 신원과 각 계정의 정상적인 사용 기준선이 필요하다. Cloudflare는 AI Gateway와 Cloudflare Access를 결합해 요청별 신원을 확인하고, User Insights로 계정별 사용 패턴에서 벗어난 행동을 탐지한다고 밝혔다. 이를 통해 비용 관리뿐 아니라 과도한 사용이나 악성·오작동 에이전트 탐지까지 가능하게 한다. ## AI Gateway를 통한 중앙 관리 - AI Gateway는 OpenAI, Anthropic, Google, Workers AI 등 여러 모델로 향하는 요청을 하나의 제어 지점으로 통합한다. - 애플리케이션뿐 아니라 Claude Code, Codex, GitHub Copilot 같은 개발자용 에이전트도 동일한 관찰·보안·거버넌스 정책을 적용할 수 있다. - 모든 AI 트래픽을 한곳에서 분석하므로 비용, 모델 사용량, 접근 제어를 통합 관리할 수 있다. ## Cloudflare Access 기반의 신원 확인 - AI Gateway 앞에 사용자 정의 도메인을 두고 Cloudflare Access로 보호할 수 있다. - Okta, Entra 등 SAML을 지원하는 ID 공급자를 이용해 인증하며, 별도의 Cloudflare API 키를 배포할 필요가 없다. - 인증된 요청에는 사용자의 Access ID가 `cf.user_id` 메타데이터로 포함된다. - 관리자는 실제 요청자를 기준으로 로그, 분석 데이터, 비용을 필터링할 수 있다. - 공유 API 키 때문에 누가 얼마나 사용했는지 알기 어려웠던 문제를 해결한다. ## 사용자별 비용 한도와 정책 - `cf.user_id`를 기반으로 사용자마다 독립적인 예산 한도를 설정할 수 있다. - 한도에 도달하면 요청을 차단하거나 더 저렴한 모델로 자동 전환할 수 있다. - 향후 ID 공급자의 그룹 정보와 연동해 팀별로 모델 접근 권한과 지출 한도를 설정할 예정이다. - 머신러닝 팀에는 최고급 모델 허용 - 지원팀에는 지출 상한 적용 - 특정 프로젝트 구성원에게 공동 예산 할당 ## User Insights의 역할 - User Insights는 AI Gateway를 통과하는 기존 트래픽을 별도 설정 없이 분석한다. - 사람과 에이전트 각각의 평소 행동 패턴을 학습하고, 그 패턴에서 벗어난 계정을 보여준다. - 비용뿐 아니라 캐시 적중률이 낮거나 컨텍스트 윈도우가 과도하게 큰 등 비용 낭비 요인도 추적한다. - 단순히 “많이 사용했는가”가 아니라 “그 계정의 평소 사용 방식과 다른가”를 판단하는 데 초점을 둔다. ## 사람과 에이전트별 행동 기준선 - 계정은 사용자든 에이전트든 시간에 따라 고유한 행동 패턴을 만든다. - 일정한 간격으로 티켓을 요약하는 에이전트와, 프롬프트·세션 길이가 불규칙한 사람은 정상 패턴이 다르다. - 따라서 모든 계정에 동일한 절대 비용 기준을 적용하면 오탐이 많아진다. - 평소 비용이 큰 사용자의 500달러 지출은 정상일 수 있다. - 평소 5달러를 쓰는 에이전트의 50달러 세션은 10배 증가한 이상 징후일 수 있다. ## 세션 비용 기반 이상 탐지 - User Insights는 개별 요청이 아니라 세션 단위로 비용을 평가한다. - 최근 30일 동안 해당 계정의 세션 비용 p95를 개인 기준선으로 사용한다. - 세션 비용이 개인 p95의 2배를 초과하면 이상 행동 후보로 분류한다. - 단, 상대적 급증만으로는 부족하므로 조직 전체 세션 비용의 p99도 함께 사용한다. - 최종적으로 다음 조건을 모두 만족하는 세션만 경고 대상이 된다. - 해당 계정의 최근 기준선보다 2배 이상 비쌈 - 조직 전체 세션 중 가장 비싼 1% 수준에 해당함 - 절대 비용 하한선도 적용해, 소액 사용자의 몇 센트짜리 급증이 불필요한 경고를 발생시키지 않도록 한다. ## 동적으로 갱신되는 기준선 - 기준선은 고정값이 아니라 계정의 최근 사용 습관에 따라 계속 변한다. - 계정의 rolling p95와 2배 임계값이 이동하므로 현재 행동에 맞는 경고가 가능하다. - 정상적인 고사용자 활동은 제외하고, 평소 패턴을 깨면서도 실제 조사 가치가 있는 고비용 세션만 추린다. - 결과적으로 관리자는 정상 트래픽을 모두 살펴보는 대신, 의심스러운 계정 중심의 “rogue behavior feed”를 확인할 수 있다. ## 보안과 비용 관리의 결합 - 이상 사용은 새로운 도구나 명백히 차단된 행동으로 나타나지 않을 수 있다. - 이미 권한을 가진 계정이나 서비스 계정이 허용된 작업을 평소보다 훨씬 많이 수행하는 방식으로 나타날 수 있다. - 따라서 사용자 신원 확인과 행동 기준선 분석을 함께 적용해야 비용 폭증과 보안 위험을 동시에 발견할 수 있다. 실무적으로는 모든 AI 요청을 AI Gateway로 통합하고, Cloudflare Access로 개인·에이전트 신원을 연결한 뒤, 사용자별 예산과 User Insights의 상대적 기준선을 함께 활용하는 방식이 권장된다.

gitlab

제한된 액세스로 GitLab 좌석을 관리하세요 (새 탭에서 열림)

GitLab의 **Restricted access**는 구매한 라이선스 좌석이 모두 사용된 뒤 새로운 과금 대상 사용자가 추가되는 것을 막아 좌석 초과와 예기치 않은 비용을 줄이는 기능입니다. SAML·SCIM·LDAP 기반 프로비저닝, OIDC/SSO 재로그인, 휴면 사용자 재활성화까지 처리 방식이 개선되어 자동화된 사용자 관리 환경에서도 더 안정적으로 사용할 수 있습니다. 다만 기존 초과 사용자를 자동으로 정리하지는 않으므로, 이미 발생한 초과분은 관리자가 별도로 해결해야 합니다. ## Restricted access의 역할 - GitLab.com과 Self-Managed에서 사용할 수 있는 좌석 제어 기능입니다. - 라이선스 좌석이 모두 소진되면 새로운 **과금 대상 사용자(billable user)** 추가를 차단합니다. - 좌석 초과를 사후에 되돌리는 기능이 아니라, 앞으로 발생할 추가 초과를 예방하는 기능입니다. - 프로젝트나 그룹 접근 없이 인증만 필요한 사용자는 **Minimal Access** 역할로 지정할 수 있습니다. - Minimal Access 사용자는 인증은 가능하지만 유료 좌석을 소비하지 않습니다. ## 기존 과금 사용자는 소급 적용되지 않음 - Restricted access를 이미 좌석 한도 초과 상태에서 활성화해도 기존 사용자는 영향을 받지 않습니다. - 기존 멤버가 자동으로 강등되거나 제거되거나 접근 차단되지 않습니다. - 관리자는 초과된 과금 사용자를 제거하거나 추가 좌석을 구매해 사용량을 한도 이내로 되돌려야 합니다. - 사용량이 한도 이내로 내려간 뒤부터 Restricted access가 추가적인 좌석 초과를 방지합니다. ## ID 프로바이더 기반 프로비저닝 개선 - 좌석이 없을 때 SAML, SCIM, LDAP로 프로비저닝된 사용자는 과금 역할로 바로 추가되지 않습니다. - 대신 자동으로 비과금 역할인 Minimal Access가 할당됩니다. - 중앙 집중식 계정 동기화를 유지하면서도 즉시 라이선스 초과가 발생하는 것을 막을 수 있습니다. - GitLab을 OIDC 프로바이더로 사용하는 경우, 인증만 필요한 사용자를 최상위 그룹에서 Minimal Access로 지정하는 방식이 유용합니다. - Minimal Access 사용자와 해당 역할만 가진 사용자는 좌석이 없어도 재활성화할 수 있습니다. ## 휴면 사용자 재활성화 문제 해결 - GitLab은 일정 기간 활동이 없는 사용자를 자동 비활성화해 좌석을 회수할 수 있습니다. - 이전에는 해당 사용자가 OIDC나 SSO로 다시 로그인하면 과금 사용자로 조용히 재활성화되어 좌석 초과가 발생할 수 있었습니다. - 이제 좌석이 부족하고 Restricted access가 활성화된 경우, 휴면 사용자는 **관리자 승인 대기 상태**로 전환됩니다. - 기존 그룹·프로젝트 멤버십은 유지됩니다. - 좌석이 확보되면 관리자가 사용자를 승인해 재활성화할 수 있습니다. ## 경고와 운영 가시성 강화 - LDAP 동기화, SAML 그룹 연결, SCIM 프로비저닝 설정 시 Restricted access의 동작을 안내하는 경고가 표시됩니다. - 좌석 한도에 접근 중인 상태와 한도에 도달한 상태가 제품 내에서 구분됩니다. - 좌석 부족으로 사용자가 Minimal Access로 배정되면 그룹 소유자나 인스턴스 관리자에게 이메일 알림이 전송됩니다. - Minimal Access로 전환된 이벤트는 감사 로그에서 확인할 수 있습니다. - 단순히 사용자 추가를 차단하는 것을 넘어, 왜 그런 처리가 발생했는지 추적하고 관리할 수 있게 개선되었습니다. ## Self-Managed의 설정 캐시 - GitLab Self-Managed는 성능을 위해 애플리케이션 설정을 기본적으로 60초간 캐시합니다. - Restricted access와 user cap 사이를 전환한 직후에는 UI나 좌석 제어 동작이 즉시 반영되지 않을 수 있습니다. - 캐시는 자동으로 갱신되며, 갱신 후에는 설정이 일관되게 적용됩니다. - 필요하다면 관리자가 캐시 간격을 조정할 수 있습니다. ## Restricted access와 user cap의 차이 - **User cap** - 좌석 여유 여부와 관계없이 새 사용자를 승인 대기 상태로 보냅니다. - 관리자나 그룹 소유자가 모든 신규 사용자 추가를 검토하는 승인 제어 기능입니다. - **Restricted access** - 라이선스 좌석이 모두 사용된 경우에만 신규 과금 사용자 추가를 제한합니다. - 구매한 좌석 수를 기준으로 동작하는 좌석 한도 제어 기능입니다. - 두 기능은 동시에 활성화할 수 없습니다. - Restricted access를 활성화하면 user cap은 자동으로 비활성화됩니다. - GitLab.com에서 user cap에서 Restricted access로 전환할 때 기존 대기 멤버의 상태가 영향을 받을 수 있으므로 전환 전에 관련 동작을 확인해야 합니다. ## 활성화 방법 - **GitLab.com** - `Settings > General > Permissions and group features > Seat control > Restricted access` - 그룹 Owner가 설정할 수 있습니다. - **Self-Managed** - `Admin > Settings > General > New user account restrictions > Seat control > Restricted access` - 관리자만 설정할 수 있습니다. - GitLab.com에서는 최상위 그룹이 외부 그룹과 공유된 경우 Restricted access를 사용할 수 없습니다. 자동 프로비저닝과 SSO를 사용하는 조직이라면 Restricted access를 활성화해 좌석 초과를 예방하는 것이 좋습니다. 다만 활성화 전 이미 발생한 초과 사용자는 별도로 정리하고, user cap과의 차이 및 기존 대기 사용자 처리 방식을 검토해야 합니다.

gitlab

GitLab 패치 릴리스: 19.0.2, 18.11.5, 18.10.8 | GitLab 문서 (새 탭에서 열림)

2026년 6월 10일 GitLab은 CE/EE용 패치 버전 19.0.2, 18.11.5, 18.10.8을 출시했다. 이번 릴리스에는 계정 탈취, XSS, 서비스 거부, SSRF, 권한 우회 등 다수의 보안 취약점이 포함되어 있어 모든 자체 관리형 설치 환경에 즉시 업그레이드가 권고된다. GitLab.com은 이미 패치가 적용됐으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 보안 및 주요 버그를 수정하기 위한 버전이다. - 정기 패치는 매월 둘째·넷째 수요일에 배포되며, 심각도가 높은 취약점에는 비정기 긴급 패치가 제공될 수 있다. - 영향을 받는 버전을 사용하는 모든 설치 유형(Omnibus, 소스 코드, Helm Chart 등)은 가능한 한 빨리 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점의 상세 이슈는 수정 릴리스 후 30일이 지나면 공개된다. ## 계정 탈취와 권한 검증 문제 - **CVE-2026-6552 — Group SAML Identity API** - GitLab EE 대상 취약점이다. - 그룹 Owner 권한의 인증 사용자가 잘못된 권한 검증을 악용해 다른 그룹 구성원의 GitLab 계정을 탈취할 수 있었다. - CVSS **8.7**로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - **CVE-2026-6269 — Merge Requests API** - CE/EE 모두 영향을 받는다. - Developer 권한 사용자가 숨겨진 머지 리퀘스트를 수정할 수 있었다. - CVSS **5.4**다. - **CVE-2026-6277 — Security Inventory** - GitLab EE 대상이다. - Security Manager가 관련 기능이 비활성화된 상태에서도 프로젝트 보안 설정을 변경할 수 있었다. - CVSS **4.3**이다. - **CVE-2026-6976 — Merge Request diff** - 파일명 처리와 권한 검증 문제로 Developer가 머지 리퀘스트 diff에서 변경 사항을 숨길 수 있었다. - CVSS는 **3.7**로 평가됐다. ## XSS 및 HTML 입력값 검증 문제 - **CVE-2026-10087 — Analytics Dashboard** - GitLab EE 대상이다. - Developer 권한 사용자가 입력값 검증 미흡을 이용해 대상 사용자의 권한으로 임의의 클라이언트 측 코드를 실행할 수 있었다. - CVSS **8.7**이며, 사용자의 상호작용이 필요하다. - **CVE-2026-8589 — 그룹 설정 필드** - GitLab EE 대상이다. - 악의적인 입력을 통해 대상 사용자 계정에 승인되지 않은 이메일 주소를 추가할 수 있었다. - CVSS **7.3**이다. - **CVE-2026-10733 — CI/CD Catalog** - CE/EE 모두 영향을 받는다. - 부적절한 입력값 정제로 인해 인증 사용자가 CI/CD Catalog 페이지에서 서비스 거부를 유발할 수 있었다. - CVSS **4.3**이다. ## 서비스 거부 및 리소스 고갈 - **CVE-2026-7250 — Grape API JSON 파싱 미들웨어** - CE/EE의 API 요청 파싱 과정에서 입력값 검증이 부족했다. - 인증하지 않은 공격자가 조작된 요청을 보내 서비스 거부를 일으킬 수 있었다. - CVSS **7.5**로, 외부에 노출된 API 서버에 특히 중요하다. - **CVE-2026-1500 — Group Placeholder Reassignments API** - 특수하게 제작된 파일 업로드를 처리하는 과정에서 리소스가 과도하게 소비될 수 있었다. - 인증된 사용자가 서비스 거부를 유발할 수 있으며, CVSS는 **6.5**다. ## SSRF와 내부 데이터 접근 - **CVE-2026-9204 — Gitaly 저장소 가져오기** - 저장소 가져오기 과정에서 보조 URL 검증이 충분하지 않았다. - 인증된 사용자가 Gitaly 서버의 임의 파일을 읽거나 내부 네트워크 리소스에 접근할 가능성이 있었다. - CVSS **5.3**이며, 서버 측 요청 위조(SSRF) 유형의 취약점이다. ## 적용 대상 버전 - **19.0.2**: GitLab 19.0 계열의 이전 버전 - **18.11.5**: GitLab 18.11 계열의 이전 버전 - **18.10.8**: GitLab 18.10 계열의 이전 버전 - 취약점별로 GitLab 12.10, 13.1.4, 15.x, 17.x 등 다양한 이전 버전이 영향을 받는다. - 취약점에 따라 GitLab EE만 영향을 받거나 CE/EE 모두 영향을 받는다. 자체 관리형 GitLab 운영자는 현재 버전의 지원 브랜치에 맞춰 19.0.2, 18.11.5, 18.10.8 중 해당되는 버전으로 즉시 업그레이드하고, 외부 공개 API와 Gitaly 접근 로그도 함께 점검하는 것이 좋다.

aws

Amazon Cognito 다중 리전 복제로 애플리케이션 복원력 향상 | Amazon Web Services (새 탭에서 열림)

Amazon Cognito의 다중 리전 복제는 사용자 인증과 M2M 인증을 보조 리전에서도 지속할 수 있도록 해 애플리케이션의 복원력을 높인다. 기본 리전의 사용자 프로필, 자격 증명, 머신 시크릿, 풀 설정을 보조 리전에 자동 복제하며, 장애 전환 시 기존 사용자의 재로그인이나 강제 비밀번호 재설정을 줄일 수 있다. 다만 사용자 등록·프로필 수정은 장애 전환 중 제한되며, KMS 키와 애플리케이션·주변 AWS 리소스에 대한 별도 구성이 필요하다. ## 기존 멀티 리전 인증의 문제 - 리전 간 Cognito 설정과 사용자 데이터를 일관되게 유지하려면 팀이 직접 복제 시스템을 구축·운영해야 했다. - 사용자 데이터를 수동으로 내보내고 가져오는 과정에서 다음 문제가 발생했다. - 민감한 인증 데이터 노출 위험 - 리전 간 데이터 불일치 - 장애 전환 시 강제 비밀번호 재설정 및 재인증 - M2M 인증에서는 보조 리전에 새 앱 클라이언트를 만들고, 애플리케이션과 OAuth 리소스가 새 리전의 토큰 발급자를 신뢰하도록 재구성해야 했다. ## Cognito 다중 리전 복제 방식 - 기본 리전에서 선택한 보조 AWS 리전으로 데이터를 단방향 복제한다. - 다음 항목이 복제된다. - 사용자 프로필 - 사용자 자격 증명 - 머신 인증용 시크릿 - 사용자 풀 구성 - 보조 리전은 읽기 전용으로 동작하며 인증 지속성을 제공한다. - 양쪽 리전이 서로 발급한 액세스 토큰을 인식하므로, 기존 로그인 세션을 유지할 수 있다. - 다음 인증 방식을 지원한다. - Amazon, Google, Apple, Facebook 등 소셜 로그인 - SAML 및 OIDC 연동 - API 및 M2M 인증 흐름 - 장애 전환 중에는 인증은 가능하지만 신규 사용자 등록이나 사용자 프로필 변경은 사용할 수 없다. ## 고객 관리형 KMS 키 - 복제를 구성하려면 AWS KMS에 저장된 멀티 리전 고객 관리형 키가 필요하다. - 동일한 암호화 키를 리전 간 복제해 사용자 데이터 저장 시 일관된 암호화 정책을 적용한다. - Cognito가 키를 사용할 수 있도록 KMS 키 정책에 권한을 추가해야 한다. - 고객 관리형 키를 사용하면 AWS 기본 키에만 의존하지 않고 조직의 암호화 및 키 관리 전략을 적용할 수 있다. ## 복제 설정 절차 예시로 `us-west-2`의 사용자 풀을 `us-east-1`로 복제한다. 1. **고객 관리형 KMS 키 설정** - 두 리전에 키를 생성·복제한다. - KMS 키 정책에 Amazon Cognito의 키 사용 권한을 추가한다. 2. **멀티 리전 OIDC 엔드포인트 설정** - 콘솔에서 새로운 OIDC issuer 유형을 활성화한다. - 변경된 엔드포인트를 서버 애플리케이션과 모바일 앱에 반영한다. - 서버는 재배포가 필요하고, 모바일 앱은 App Store와 Google Play에 업데이트를 제출해야 할 수 있다. - 엔드포인트를 변경하지 않으면 기존 인증 요청이 올바르게 라우팅되지 않아 사용자 장애가 발생할 수 있다. 3. **복제 대상 리전 선택** - 고객 관리형 키가 복제된 리전만 대상 리전으로 선택할 수 있다. - 데이터 규모에 따라 복제 준비 시간이 달라진다. - 복제 사용자 풀이 준비되면 관리자가 수동으로 활성화해야 한다. ## 장애 전환과 트래픽 라우팅 - 기본 리전과 보조 리전의 엔드포인트는 항상 활성 상태로 유지된다. - 애플리케이션 요구사항에 맞춰 다음 항목을 기준으로 헬스 체크를 설계할 수 있다. - 인증 오류율 - 지연 시간 증가 - 특정 AWS 서비스 장애 알림 - 장애 조건이 충족되면 DNS를 변경해 보조 리전으로 트래픽을 전환한다. - 실제 장애 전에 비업무 시간에 일부 트래픽만 보조 리전으로 보내 인증 흐름을 검증하는 것이 권장된다. - 관리형 로그인과 사용자 지정 도메인 기반 연동에서는 Route 53 헬스 체크 ID를 이용한 내장 트래픽 라우팅도 사용할 수 있다. ## 추가로 준비해야 할 리소스 다중 리전 복제 자체만으로 모든 인증 관련 리소스가 자동 복제되는 것은 아니다. - 사용자 지정 인증 흐름에 사용하는 Lambda 함수를 대상 리전에 배포해야 한다. - SMS 및 이메일 알림 설정도 대상 리전에서 별도로 구성해야 한다. - 로그 스트리밍 설정과 AWS WAF 규칙을 수동으로 복제해야 한다. - 장애 전환 절차, DNS 변경, 보안 정책을 사전에 문서화하고 테스트해야 한다. ## 가격과 제공 리전 - Essentials 및 Plus 요금제의 추가 기능으로 제공된다. - 사용자 인증 비용: - Essentials: 복제 리전별 월간 활성 사용자당 `$0.0045` - Plus: 복제 리전별 월간 활성 사용자당 `$0.006` - M2M 인증은 성공적으로 발급된 토큰의 표준 볼륨 요금에 30%가 추가된다. - 미국, 캐나다, 유럽, 아시아 태평양, 남미 등 여러 리전에서 제공되며, 지원 리전은 기본 리전과 복제 대상 리전 모두로 사용할 수 있다. ## 실용적인 권장 사항 다중 리전 복제는 인증 중단을 최소화해야 하는 고객-facing 서비스와 M2M 백엔드에 적합하다. 도입 전 KMS 키, OIDC 엔드포인트, Lambda·WAF·로그 설정을 함께 준비하고, 인증 지속성과 장애 전환 후의 읽기 전용 제약을 포함한 실제 장애 대응 테스트를 수행하는 것이 좋다.

aws

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 비용 별도) 즉시 도입할 수 있습니다.

figma

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

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 모듈을 결합하는 방식이 효과적이다. 특히 네트워크 위치를 신뢰 기준으로 삼지 않고, 강력한 사용자 인증과 중앙화된 그룹·권한 관리를 적용하는 것이 중요하다.

figma

Figma 데이터의 안전한 보호 및 (새 탭에서 열림)

Figma는 고객의 디자인 데이터와 지식재산을 보호하기 위해 보안을 제품 개발과 인프라 운영 전반의 핵심 원칙으로 삼고 있다. SOC 2 인증, 유럽 데이터 보호 체계, 플러그인 권한 제한, SAML 기반 SSO 등을 통해 규정 준수와 실제 서비스 보안을 함께 강화했다. 이후 업데이트에서는 SOC 2 Type 2와 SOC 3 보고서까지 취득해 내부 통제가 일정 기간 안정적으로 작동했음을 입증했다. ## SOC 2 인증으로 검증한 보안 통제 - SOC 2는 클라우드에 저장된 고객 데이터를 보호하기 위한 미국 소프트웨어 기업의 대표적인 보안 준수 기준이다. - 인증 과정에서 인프라, 소프트웨어, 인사 절차, 고객 데이터 처리 정책과 통제를 종합적으로 감사한다. - SOC 2 Type 1은 특정 시점에 통제가 마련되어 있는지를 확인하는 일종의 스냅샷이다. - SOC 2 Type 2는 통제가 일정 기간 실제로 작동했는지까지 검증하므로 더 높은 수준의 보증을 제공한다. - Figma는 글 작성 당시 Type 1 인증을 완료하고 Type 2를 추진 중이었으며, 2020년 업데이트에서 SOC 2 Type 2와 SOC 3 보고서 취득을 발표했다. ## 유럽 고객을 위한 데이터 보호와 준수 - 유럽 고객 증가에 맞춰 EU와 국제적인 데이터 보호 및 보안 요구사항을 충족하는 것을 목표로 했다. - EU-US Privacy Shield와 Swiss-US Privacy Shield 프레임워크 인증을 취득했다. - 이를 통해 유럽 및 스위스 고객이 Figma에 디자인 데이터를 저장할 때 필요한 개인정보 보호 체계를 마련했다고 설명한다. ## 기능 개발 단계부터 적용한 보안 원칙 - 보안은 별도의 사후 검토가 아니라 새로운 기능을 설계하고 개발하는 단계부터 고려하는 원칙으로 제시된다. - 특히 Figma Plugins처럼 외부 개발자가 플랫폼을 확장하는 기능은 보안·안정성·성능 사이의 균형이 중요했다. - 플러그인은 한 번에 하나의 디자인 파일에만 접근할 수 있다. - 플러그인이 사용자의 전체 계정이나 다른 플러그인의 데이터에 접근할 수 없도록 격리했다. - 플러그인이 Figma UI를 변경하지 못하게 해 사용자를 속이거나 피싱으로 유도할 가능성을 줄였다. - 일부 기능과 확장성을 제한하더라도 고객 데이터 보호를 우선한 설계 결정이었다. ## SAML SSO를 통한 기업 계정 관리 - 기업 고객을 위해 SAML 기반 싱글 사인온(SSO)을 지원했다. - SSO는 로그인 절차를 단순화하는 동시에 조직 전체에 Figma를 배포하고 사용자 접근 권한을 중앙에서 관리할 수 있게 한다. - 기존 Okta와 Microsoft Azure Active Directory에 더해 OneLogin도 통합 대상으로 추가했다. - 기업은 기존 인증·접근 관리 체계와 Figma를 연결해 퇴사자 계정 차단이나 사용자 권한 관리 등을 일관되게 운영할 수 있다. ## 실용적인 시사점 Figma의 사례는 SaaS 보안에서 인증서 취득만으로 끝나는 것이 아니라, 장기간 작동하는 내부 통제와 기능별 권한 격리, 기업용 접근 관리까지 함께 구축해야 한다는 점을 보여준다. 특히 플러그인이나 확장 기능을 도입할 때는 가능한 기능을 늘리는 것보다 데이터 접근 범위를 최소화하고 사용자 신뢰를 보호하는 설계가 우선되어야 한다.