gitlab2026년 7월 6일

제한된 액세스로 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과의 차이 및 기존 대기 사용자 처리 방식을 검토해야 합니다.

openid-connectgitlabidentity-providersaml+4

aws2026년 6월 3일

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·로그 설정을 함께 준비하고, 인증 지속성과 장애 전환 후의 읽기 전용 제약을 포함한 실제 장애 대응 테스트를 수행하는 것이 좋다.

openid-connectaws-lambdaoauthsaml+4

github2026년 4월 1일

GitHub 전반의 오픈 소스 공급망 보안 강화 (새 탭에서 열림)

공격자들은 GitHub Actions 워크플로를 침해해 API 키 같은 비밀을 탈취한 뒤, 악성 패키지를 배포하고 더 많은 프로젝트로 공격을 확산시키고 있다. 이에 대응하려면 Actions 워크플로를 CodeQL로 점검하고, 서드파티 액션을 커밋 SHA로 고정하며, 장기 비밀 대신 OIDC 기반 인증과 trusted publishing을 사용해야 한다. GitHub는 npm 악성코드 탐지와 Actions·npm 보안 로드맵을 강화하고 있지만, 오픈소스 생태계 전반의 지속적인 협력이 필요하다고 강조한다. ## GitHub Actions 워크플로가 공격의 출발점 - 최근 오픈소스 공급망 공격은 GitHub Actions 워크플로의 취약점을 찾는 방식으로 시작되는 경우가 많다. - 공격자는 워크플로에서 API 키, 토큰, 배포 자격 증명 등의 비밀을 탈취한다. - 탈취한 자격 증명으로: - 공격자가 통제하는 환경에서 악성 패키지를 배포하고 - 해당 패키지를 이용해 다른 프로젝트와 계정으로 공격을 확산한다. ## 지금 적용할 수 있는 Actions 보안 조치 - 공개 저장소에서 무료로 사용할 수 있는 **CodeQL의 GitHub Actions 분석 기능**을 활성화한다. - 워크플로 구현상의 보안 취약점과 보안 모범 사례 위반을 점검할 수 있다. - `pull_request_target`을 사용하지 않는다. - 외부 기여자의 코드가 높은 권한의 워크플로 컨텍스트에서 실행될 위험이 있다. - 서드파티 GitHub Actions를 전체 길이의 커밋 SHA로 고정한다. - 태그나 브랜치는 이후 다른 코드로 변경될 수 있지만, SHA 고정은 특정 코드 버전을 보장한다. - 이 변경은 저장소 관리자나 Dependabot이 수행해야 하며, 외부 Pull Request가 액션 버전 고정을 바꾸려 하면 주의해야 한다. - 사용자 입력을 셸 명령이나 스크립트에 직접 삽입하지 않는다. - 이 방식은 스크립트 인젝션으로 이어질 수 있다. - 침해된 의존성은 GitHub Advisory Database에서 확인한다. - Dependabot을 사용해 악성 또는 취약한 의존성에 대한 알림을 받는다. ## 비밀 대신 OIDC와 trusted publishing 사용 - 워크플로에 장기 보관되는 비밀을 넣는 대신, **OpenID Connect(OIDC) 토큰**을 사용할 수 있다. - OIDC 토큰에는 실행 중인 워크로드의 신원이 포함되므로, 클라우드 제공업체·패키지 저장소·호스팅 서비스가 해당 워크플로를 검증하고 권한을 부여할 수 있다. - GitHub와 OpenSSF는 이를 패키지 저장소의 **trusted publishing**으로 확산하고 있다. - 현재 npm, PyPI, NuGet, RubyGems, Crates 등 여러 저장소에서 지원된다. - trusted publishing의 장점: - 빌드 파이프라인에서 장기 비밀을 제거한다. - 패키지가 어떤 신뢰된 워크플로에서 배포됐는지 확인할 수 있다. - 패키지가 갑자기 trusted publishing을 중단하면, 탈취된 자격 증명을 이용한 공격 가능성을 조사하는 신호가 된다. ## npm의 악성 패키지 탐지 - npm에서는 매일 3만 개가 넘는 패키지가 배포된다. - GitHub는 모든 npm 패키지 버전을 악성코드 관점에서 검사한다. - 탐지 규칙은 공격 방식의 변화에 맞춰 지속적으로 개선된다. - 매일 수백 개의 신규 배포 패키지에서 악성 코드가 발견될 수 있으며, 실제 조치 전에는 사람이 양성 여부를 검토한다. - 오탐률이 1%만 되어도 매일 수백 개의 정상 패키지 배포가 중단될 수 있으므로, 자동 탐지와 사람의 검증 사이 균형이 중요하다. ## Shai-Hulud 이후의 보안 로드맵 - 2025년 말 발생한 Shai-Hulud 공격은 npm 보안 로드맵을 재정비하는 계기가 됐다. - GitHub는 다음 작업을 가속했다. - npm trusted publishing 확대 - 악성코드 탐지 및 제거 기능 강화 - 오픈소스 유지관리자와의 보안 요구사항 논의 - 보안 변경은 기존 워크플로를 수정하게 만들거나 하위 호환성을 깨뜨릴 수 있으므로, GitHub는 생태계가 원활하게 전환할 수 있도록 지원할 계획이다. - 최근 공격을 계기로 GitHub Actions 보안 로드맵도 재검토하고, 이미 진행 중인 보안 기능의 출시를 앞당기고 있다. ## 오픈소스 생태계의 공동 대응 - 오픈소스는 전 세계가 공유하는 공공재인 만큼 공격이 앞으로도 계속될 가능성이 높다. - GitHub는 npm과 GitHub Actions를 비롯해 향후 등장할 새로운 공격 경로까지 방어 범위를 확대하겠다고 밝혔다. - 효과적인 보안 기능을 만들기 위해 유지관리자와 커뮤니티의 피드백이 중요하다. 실무적으로는 먼저 CodeQL로 Actions를 검사하고, `pull_request_target` 제거·커밋 SHA 고정·스크립트 인젝션 점검을 진행하는 것이 좋다. 이후 가능하면 OIDC와 trusted publishing으로 배포 인증을 전환해, 탈취 가능한 장기 비밀 자체를 줄여야 한다.

openid-connectgithub-actionsnpmsupply-chain-security+3

cloudflare2026년 3월 4일

딥페이크 격퇴: 노트북 (새 탭에서 열림)

현대 보안 아키텍처에서 신뢰는 가장 위험한 취약점이 되었으며, 특히 생성형 AI와 딥페이크를 이용한 원격 IT 노동자 사기가 새로운 위협으로 급부상하고 있습니다. 클라우드플레어(Cloudflare)는 이를 해결하기 위해 신원 검증 전문 기업 네임태그(Nametag)와 파트너십을 맺고, 기기나 자격 증명을 넘어 '실제 사람'을 확인하는 신원 보증 기반의 제로 트러스트 모델을 제시합니다. 이 솔루션은 노트북 팜(Laptop farms)과 같은 조직적 침투 시도를 차단하고 온보딩부터 업무 수행 전 과정에 걸쳐 강력한 신원 확인 계층을 추가하는 것을 골자로 합니다. ### "원격 IT 노동자" 사기와 노트북 팜의 진화 * **조직적 침투:** 북한 등 국가 차원의 지원을 받는 공격자들이 도용된 신원과 딥페이크 기술을 사용해 원격 개발자로 취업한 뒤, 지적 재산권을 탈취하고 자금을 유출하는 사례가 급증하고 있습니다. * **노트북 팜(Laptop Farm)의 실체:** 공격자는 국내 거점에 노트북을 배송시킨 뒤 KVM 스위치와 VPN을 통해 원격으로 접속합니다. 보안 시스템 입장에서는 기업이 지급한 정식 기기에서 유효한 자격 증명으로 접속하는 것으로 보여 탐지가 매우 어렵습니다. * **신원 보증의 공백:** 기존 제로 트러스트 모델은 기기의 상태와 계정 정보는 검증하지만, 정작 키보드 앞에 앉아 있는 '사람'이 누구인지는 확인하지 못하는 허점이 있습니다. ### Nametag을 통한 신원 검증 기반 제로 트러스트 * **물리적 신원 확인:** 클라우드플레어 액세스(Cloudflare Access)에 네임태그의 신원 검증 기술을 통합하여, 신규 입사자 온보딩이나 민감 데이터 접근 시 실제 인물을 대조합니다. * **딥페이크 방어(Deepfake Defense™):** AI와 고급 암호화 기술을 활용해 사진을 카메라에 비추는 프리젠테이션 공격이나 고도로 조작된 딥페이크 영상을 통한 우회 시도를 차단합니다. * **신뢰 추정의 폐기:** 원격 근무 환경에서 이메일로 초기 비밀번호를 보내는 식의 '가정된 신뢰'를 배제하고, 정부 발행 신분증과 생체 인식 정보를 기반으로 한 '검증된 신뢰'로 대체합니다. ### 신원 검증 워크플로우 및 작동 방식 * **OIDC 통합:** 네임태그는 OpenID Connect(OIDC)를 통해 클라우드플레어 액세스의 신원 제공업체(IdP)로 설정되거나 기존 IdP(Okta, Azure AD 등)와 체이닝되어 작동합니다. * **검증 프로세스:** 사용자가 온보딩 포털에 접속하면 네임태그 인증이 실행됩니다. 사용자는 스마트폰으로 정부 발행 신분증을 스캔하고 셀카를 촬영하여 본인임을 증명합니다. * **즉각적인 통제:** 검증은 30초 이내에 완료되며, 성공 시에만 OIDC 토큰이 클라우드플레어로 반환되어 내부 리소스 접근이 허용됩니다. 검증 과정에서 사용된 생체 정보는 저장되지 않아 개인정보를 보호합니다. ### 다층 방어와 지속적인 위험 관리 * **통합 보안 시너지:** 신원 검증은 기존의 데이터 유출 방지(DLP), 원격 브라우저 격리(RBI), 클라우드 접근 보안 중개(CASB)와 결합하여 더욱 강력한 내부 위협 방어 체계를 형성합니다. * **사용자 위험 점수:** 클라우드플레어 액세스는 사용자 위험 점수를 실시간으로 반영합니다. 정상적인 직원이더라도 계정 탈취가 의심되거나 위험 점수가 상승하면 즉시 접근을 차단하거나 재인증을 요구합니다. AI가 얼굴과 목소리를 완벽하게 모방할 수 있는 시대에 더 이상 단순한 아이디와 패스워드만으로는 보안을 유지할 수 없습니다. 원격 근무 인력을 운영하는 기업은 하드웨어와 자격 증명 중심의 보안을 넘어, 암호학적으로 증명된 생체 기반 신원 확인을 제로 트러스트 정책의 필수 요소로 도입해야 합니다.

openid-connectaicloudflarezero-trust+4