이런 문제를 이미 가지고 있을 것입니다.
개발자는 프로덕션 액세스에 대한 핫픽스에 대한 액세스 권한이 필요합니다. 지원 팀은 한 고객의 환경을 검사해야 합니다. CI pipeline은 빌드를 배포할 수 있지만, 어떤 토큰을 사용했는지, 누구도 승인했는지, 또는 3개의 다른 시스템에 아직 존재하는지에 대한 확신을 가지고 있지 않습니다. 모바일 앱은 하나의 서비스를 통해 인증을 하지만, Electron 데스크톱 빌드는 다른 경로를 사용하고, 라이브 업데이트 채널에는 두 명의 사람만이 이해하는 자격증이 있습니다.
그것은 단순히 엉망입니다. 그것은 약한 것입니다. Capacitor 또는 Electron을 사용하는 크로스 플랫폼 팀은 액세스가 옆으로 더 빠르게 성장합니다. 사용자 로그인만 관리하는 것이 아닙니다. 개발자 역할, 릴리스 채널, 지원 도구, CI 러너, 서명 키, 관리자 콘솔, 환경 비밀, 테스트 장치, 고객별 배포를 관리해야 합니다. 만약 그 제어들이 비공식적이면, 앱은 그 혼란을 물려받습니다.
앱 접근 관리는 이러한 분산을 시스템으로 바꾸는 학문입니다. 잘 수행하면, 누구든지 무엇을 할 수 있는지, 어디서, 그리고 어떤 조건하에 할 수 있는지에 대한 명확한 규칙을 제공합니다. 그러나 잘못 수행하면, 팀이 채팅에서 자격 증명을 공유하고 영구적인 접근 권한을 부여하는
목차
- 무질서한 접근의 숨겨진 비용
- 앱 접근 관리의 네 가지 기둥
- 접근 모델을 선택하는 것 RBAC vs ABAC
- 최신 앱의 구현 아키텍처
- 기업 앱 구현의 단계적 접근 방법
- 보안 및 운영의最佳 관행
- 기업 앱 접근 체크리스트
비정기적인 접근 관리의 숨겨진 비용
대부분의 경우 첫 번째 경고 신호는 무해하게 보입니다. alguien이 공유된 관리자 계정의 스프레드시트를 유지하고 있는 이유는 온보딩이 스프린트 사이클보다 느리기 때문입니다. 다른 팀원은 CI 시스템에 프로덕션 크레덴셜을 저장하고 있는 이유는 출시가 잘못된 시점에 막혔기 때문입니다. 계약자들은 떠났지만, 업데이트 서비스, 크래시 대시보드, 고객 지원 콘솔, 내부 스테이징 앱에서 접근 권한이 제거되었는지 확신하지 못합니다.
애플리케이션 접근 관리가 이론에서 실제로 작동하는 방식으로 변하는 곳입니다.
모바일 및 데스크톱 팀에 대한 피해는 한 번의 극적인 실수에서 오는 것이 거의 아니다. 그것은 축적된 단축키에서 오는 것이다. 공유된 Apple, Google, 또는 업데이트 서비스 자격 증명이 책임의 분산을 가져온다. 장기적인 지원 접근 권한은 감사 과정을 고통스럽게 만든다. 일회성 예외가 쌓여서 nobody도 더 이상 어떤 권한이 합법적인 작업 필요와 매핑되는지 알 수 없게 된다. 만약 세 번째-party 공급자가 침해당했다면, cleanup이 더 어려워질 때가 있다. 왜냐하면 cleanup을 하기 위해서는 빠르게 enumerate할 수 있어야 하기 때문이다. 누가 어떤 접근 권한을 가지고 있었는지 알 수 없기 때문에, 이는 왜 solid} 애플리케이션 팀의 외부 위협 대응 계획 정확한 접근 데이터가 있어야 작동합니다.
실제 상황에서 혼란의 모습은 이러하다.
- Capgo 사용자에 대한 오버프로비전이 발생합니다. 새로운 엔지니어들은 역할을 설계하는 것보다 더 빠르기 때문에 광범위한 접근 권한을 받습니다.
- 이동자들은 이전 권한을 유지합니다. 개발자는 제품이나 지원으로 전환하지만 배포 권한은 유지된다.
- 퇴근자들은 여전히 활동을 유지하고 있습니다. shipping 및 지원과 연결된 SaaS 도구는 laptop 계정을 닫는 offboarding에 의해 닫히지 않습니다.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__, 권한 인증, 및 연속 감사 한 개의 제어 평면에서 최소 권한 및 RBAC/ABAC Capgo의 IAM 기술 안내서.
IAM 기술 안내서에 설명된 정책 모델 중 주된 모델인 RBAC/ABAC
인증은 신분을 증명한다
인증은 첫 번째 질문에 답한다 누구인가?
앱의 관점에서, 이는 비밀번호, 패스 키, 장치 인증서 또는 로그인에 의해 관리되는 식별 제공자의 로그인일 수 있습니다. Capacitor 앱에서, 클라이언트는 최종 식별 권한이 아닙니다. 앱은 증거를 수집하지만 백엔드가 이를 검증하고 세션을 발급합니다. Electron에서, 이 분리는 데스크톱 셸이 더 풍부한 로컬 기능을 가지고 있으며 내부 시스템에 직접 접근하는 경우가 많기 때문에 더욱 중요합니다.
Single Sign-On SSO 승인된 채팅방에서 작동하는 마스터 배지입니다. 이는 비밀번호의 양산을 줄이고 로그인 정책을 중앙화하여 엔지니어 콘솔, 지원 대시보드, 관리자 도구 및 릴리스 시스템과 같은 곳에서 유용합니다.
세션 관리를 강화하는 것이 이에 대한 실용적인 동반자입니다. 인증 흐름이 단단하지만 세션 라이프 사이클이 부실한 경우 여전히 문제가 있습니다. 이러한 세부 사항을 처리하는 팀은 앱 스토어의 세션 관리 표준과 인증 설계를 함께 검토해야 합니다. 세션 관리 표준 앱의 사용자 대면 흐름을 명확하게 설명하는 짧은_walkthrough도 나중에 스택에서 도움이 될 수 있습니다.
권한 정의는 폭파 반경을 정의합니다.
식별성 이후 더 어려운 문제가 있습니다.
어떤 것을 허용할 수 있나요? __CAPGO_KEEP_0__
많은 팀이 사용자 인증을 올바르게 수행하지 못하고, 그 후에 사용자에게 광범위한 접근 권한을 부여하는 이유는 권한 디자인에 대한 지루함을 느끼기 때문입니다. office analogy에서, 그건 모든 직원에게 모든 층, 서버실, 그리고 금융 기록실에 열쇠가 있는 ID 카드를 주는 것입니다.
The core pieces work like this:
| 기둥 | What it answers | 앱 예시 |
|---|---|---|
| 인증 | 당신이 정말 이 인격일까? | 사용자는 IdP를 통해 로그인합니다. |
| 인가 | 이 인격이 무엇을 할 수 있을까? | 지원 팀은 로그를 볼 수 있지만 업데이트를 배포할 수는 없습니다. |
| SSO | 다중 앱에 하나의 신뢰할 수 있는 로그인 가능할까요? | 대시보드, CI, 및 관리자 콘솔에 하나의 직원 로그인 |
| 2FA | 위험한 액션에 대해 추가 증명 요구할 수 있을까요? | 생산 액세스 전에 다시 한번提示 |
2FA는 가장 중요한 순간을 보호하기 때문에 별도로 언급할 가치가 있습니다. 로그인하는 것은 한 가지 일입니다. 프로덕션 롤아웃 승인, 고객 전용 채널에 접근하거나 릴리스 정책 변경을 요구하는 것은 더 강한 증명이 필요합니다.
감독 모니터링은 팀이 너무 늦게 추가하는 네 번째 기둥입니다. 시작부터 존재해야 합니다. 제어 평면이 접근을 요청한 사람, 승인한 사람, 변경한 것, 그리고 취소한 것을 보여주지 못한다면, 앱 접근 관리를 구축하지 않았습니다. 로그인 화면만 구축했습니다.
접근 모델 선택: RBAC vs ABAC
조직은 간단한 질문으로 시작하고 그 후에 영구적인 아키텍처를 의도치 않게 선택합니다. 권한은 역할에 따라 따르거나, 또는 상황에 따라 의존해야 합니까?
RBAC와 ABAC의 결정은 실제로는 순수하게 EITHER-OR의 선택이 아닙니다. 더 좋은 질문은 각 모델이 어디에 속하는지에 대한 것입니다.
Core Security의 IAM 조사 결과 IAM은 보안 및 위험 관리에서 매우 중요하거나 매우 중요하다고 말한 조직은 90%이며, IAM 솔루션이 비인가된 액세스 사고를 줄였다고 말한 조직은 75%입니다. 2020 IAM 보고서에서 Core Security에 따르면 __CAPGO_KEEP_0__그것은 라벨 하나만으로는 얻을 수 없는 결과입니다.
작업이 수행되는 방식에 맞는 모델을 선택하는 것입니다.
RBAC는 잘 작동하는 경우 RBAC는 Role-Based Access Control의 약자입니다.
권한은 업무 역할에 부여됩니다.
제품 팀을 운영하는 경우 RBAC는 권한 부여의 조직 차트 버전입니다.
- 릴리즈 엔지니어는 스테이징에 배포할 수 있고, 지원 담당자는 테넌트 진단을 볼 수 있고, 금융 관리자는 청구를 관리할 수 있습니다. RBAC는 잘 작동하는 경우
- 업무 책임이 안정적일 때 역할이 반복 가능한 일련의 작업에 매핑될 때
- __CAPGO_KEEP_0__ 관리자들은 수백 개의 개별 권한을 검토하는 것보다 역할을 검증하는 데 더 빠릅니다.
개발자가 오버 더 에어 업데이트 또는 환경에 따라 릴리스 권한을 구현하는 경우, 이 Capacitor 앱에서 OTA 업데이트에 RBAC이 보안하는 방법에 대한 안내서 역할 기반 정책이 올바른 시작점임을 보여주는 실제 사례입니다.
백엔드가 일반 개발자 플랫폼을 사용하는 경우, Supabase 및 Firebase에 대한 RBAC 역할 설계의 추상화를 앱에 접근하는 구현 패턴으로 번역하는 유용한 설명입니다.
ABAC의 복잡성을 얻는 곳
Attribute-Based Access Control ABAC
역할 이외의 특성과 맥락에 따라 권한이 결정됩니다. 권한은 장치 상태, 고객 assign, 환경, 위치, 위험 상태, 또는 시간 창과 같은 특성과 맥락에 따라 결정됩니다. 지원 엔지니어는 assign 된 계정에 대한 로그만 볼 수 있고, 관리 디바이스에서만, 그리고 승인된 사고 기간 동안만 허용됩니다.
The moment you have to say “yes, but only if…” you’re already drifting from RBAC into ABAC.
ABAC은 규칙이 빠르게 증가하여 관리하기 어려운 것입니다. 팀은 유연하지만 읽기 어려운 정책을 만들곤 합니다. 접근 거부를 디버깅하는 속도는 느려집니다. 정책 테스트는 실제로 중요한 절차가 됩니다.
RBAC와 ABAC를 구분하는 실제적인 방법은 다음과 같습니다.
- 기본적인 권한을 RBAC로 설정합니다. 개발자, 릴리스 매니저, 지원 분석가, 보안 관리자와 같은 광범위한 경로를 정의합니다.
- _sensitive한 액션에 ABAC를 layer합니다. 생산, 고객별 데이터, 관리 장치, 시간 제한된 승격, 또는 비상 작전 워크플로에 대한 조건을 추가합니다.
- 역할爆炸를 피하십시오. 만약에 수십 개의 거의 동일한 역할을 만들고 있으면, 그 차이점을 속성으로 처리해야 한다는 신호입니다.
대부분의 Capacitor 및 Electron 팀에서 RBAC는 빠른 운영 제어를 제공합니다. ABAC는 고객 격리, 규제된 접근, 그리고 임시 특권 작업이 중요해질 때 가치가 있습니다.
현대 앱의 구현 아키텍처
아키텍처 결정은 접근 제어가 일관되게 유지되거나 산재하는지에 영향을 미칩니다.
클라이언트에 너무 많은 신뢰를 두는 일반적인 실수는 클라이언트에서 Capacitor 앱 또는 Electron 셸이 식별 정보를 제공할 수 있지만, 정책 결정은 중앙에서 관리하고 로그를 남기며 업데이트 할 수 있는 백엔드 서비스에서 살아야 합니다. 인증 로직이 모바일 클라이언트, 데스크톱 앱, API layer, 그리고 내부 도구에 중복되면 이탈은 거의 보장됩니다.
어디에 제어권이 있어야 하는지
모노리틱한 구조에서는 중앙 집중화가 더 쉽습니다. 인증은 에지로 이동하고, 세션은 하나의 서비스에서 발급되며, 권한은 비즈니스 로직과 가깝게 중간웨어 또는 전용 정책层에서 처리할 수 있습니다.
microservices의 경우 패턴이 바뀝니다. 중앙에서 인증을 수행하고, 일반적으로 identity provider를 통해 하지만, 각 서비스는 신뢰할 수 있는 방법으로 identity claims를 소비하고 scoped permissions를 강제해야 합니다. Cloudflare 또는 API와 같은 게이트웨이는 토큰 검증 및 coarse access checks를 도와줄 수 있지만, 권한 부여가 단지 여기서만 발생하는 것은 아닙니다. 게이트웨이는 호출자가 정면으로 들어갈 수 있는지 결정할 수 있지만, 서비스는 호출자가 특정 리소스에 대해 특정 작업을 수행할 수 있는지 여부를 결정해야 합니다.
자동화된 프로비저닝 및 비프로비저닝을 사용하는 SOUND 엔터프라이즈 패턴은 SSO, MFA 및 SCIM과 같은 연합 표준을 사용하여 시스템 간에 신속하게 식별 정보가 전파되도록 합니다. 이는 콘코드가 설명한 내용과 같습니다. 애플리케이션 디자인에서 IAM그것은 역할 변경과 해고가 오래된 권한이 살아남는 곳이기 때문에 중요합니다.
Capacitor과 Electron이 변경되는 것은 무엇인가요?
Capacitor과 Electron은 많은 IAM 지침이 생략하는 계층을 추가합니다. 앱은 단순히 비즈니스 API의 프론트 엔드만이 아닙니다. 앱도 릴리스 및 런타임 작업에 참여합니다.
이러한 스택에 대해 액세스를 세 개의 별개의 평면으로 다룹니다:
-
앱 기능에 대한 사용자 액세스
앱이 할 수 있는 것에 대한 사용자 인증 및 권한 -
배포 시스템에 대한 운영자 액세스
관리자 콘솔, 분석 도구, 크래시 대시보드 및 지원 포털 -
pipeline 및 업데이트 액세스
CI 작업, 서명 서비스, 아티팩트 저장소 및 실시간 업데이트 채널
이러한 평면은 자격 증명이나 신뢰 가정 공유하지 않아야 합니다.
Electron은 웹 code을 데스크톱 기능으로 연결할 수 있으므로 추가 주의가 필요합니다. 앱은 장기 보유한 권한 있는 비밀을 지역 저장소에 저장하지 않도록 해야 합니다. Capacitor 앱은 다른 위험을 encount합니다. 팀은 백엔드 API를 올바르게 의존하고, 업데이트 시스템, 빌드 도구 및 환경 저장소가 동일한 엄격성을 필요로 하는 것을 잊곤 합니다. 만약에 그 지역 데이터 경계를 강화하고 있다면, Capgo의 글을 읽어보세요. __CAPGO_KEEP_0__ 모바일 앱에 대한 보안 데이터 저장
__CAPGO_KEEP_0__
정책 결정은 서버 측에서 유지하고 클라이언트가 요청하도록 하세요. 클라이언트가 결정하지 않도록 하세요.
릴리스 작업을 위해 CI 및 업데이트 자동화에 대한 기계적 식별자를 사용하여 가장 좁은 채널 또는 환경에 범위 지정하세요. 만약 하나의 토큰이 모든 고객 스트림에 게시할 수 있다면, 배포 경로에 단일 실패 지점을 만들었습니다.
구현의 단계별 접근 방식
팀이 프로젝트 하나에서 역할 매트릭스를 급하게 만들고, 몇 가지 긴급한 예외, 그리고 해결되지 않은 경계 사례의 백로그를 만드는 경우가 많습니다. 단계별 롤아웃이 더 좋습니다. 접근 관리는 동시에 제품, 엔지니어링, 지원, IT, 및 규정 준수에 영향을 미치기 때문입니다. 그 이유로 이 카테고리는 계속해서 투자가 들어오고 있습니다. 전 세계 IAM 시장은 2022년 14.7억 달러로 평가되었으며, 2032년까지는 53.1억 달러에 이를 것으로 예상됩니다. Market.us에서 제공하는 IAM 시장 데이터에 따르면 2032년 14.7__.CAPGO_KEEP_0__은 단순히 패션에 의해 구입하는 것이 아니라 운영을 중단시키는 무조건적인 접근이 발생할 때이다.
1, 2 단계
먼저 발견과 정책 정의.
접근을 부여하는 사람, 접근을 사용하는 사람, 접근을 검토하는 사람, 접근을 제거하는 사람을 인터뷰하라. 그것은 엔지니어링 매니저, DevOps, 지원 리드, 규정 준수 소유자, 퇴사 처리를 담당하는 사람 등이다. 문서화된 실제 워크플로우를 기록하라. 위키에 적힌 프로세스만 기록하는 것이 아니다.
그 다음, 접근을 업무 기능에 매핑하라.
- 인간 역할: 개발자, QA, 지원 분석가, 릴리스 매니저, 보안 검토자
- 시스템 역할: CI 러너, 배포 봇, 모니터링 통합, 업데이트 퍼블리셔
- Sensitive scopes: 제품, 고객 특정 환경, 서명 시스템, 청구 데이터
현재 상태를 알면 어디서 구입하고 어디서 구축할지 결정할 수 있습니다. 일반적으로 조직은 인증 인프라를 구입하는 것이 효율적이고 자체 인증 스택을 구축하는 것을 피하는 것이 좋습니다. 그러나 많은 조직은 제품 권한이 그들의 애플리케이션에 특이한 경우에 따라 커스텀 인증 로직이 필요합니다.
A related area that gets overlooked early is automation security. If your rollout still uses manually shared secrets in pipelines, read Capgo’s guide on CI/CD pipeline에서 비밀 관리에 대한 가이드 아키텍처를 finalize하기 전에 읽어야 합니다.
세 번째와 네 번째 단계
다음은 통합 및 시범 테스트.
정치적으로敏感한 시스템에서 시작하지 마십시오. SSO, 역할 mapping, 감사 로깅, 승인 흐름, Deprovisioning과 같은 메커니즘을 검증할 수 있는 앱 또는 내부 도구에서 시작하십시오. 시범 테스트는 접근 권한이 요청, 부여, 사용, 검토, 취소될 수 있는지 끝까지 검증해야 합니다.
성공뿐만 아니라 실패도 좋은 시범 테스트를 한다:
- 접근 권한이 거부된 경우: 사용자가 명확한 이유를 얻을 수 있나요?
- 역할 변경: 기존 접근 권한이 수동으로 정리되지 않으면 사라지나요?
- 비상 승격: 권한이 임시로 부여되고 나중에 만료되나요?
- 퇴사 처리: 모든 연결된 시스템이 권한을 제거하기 위해 충분히 빠르게 업데이트되나요?
첫 번째 접근 모델을 구축할 때, 실제로 관리할 수 있는 권한에 따라서, 아닌 완벽한 모델에 따라서 구축하지 마세요.
마지막 단계는 배포 및 교육. 승인자와 사용자 모두에게 교육을 제공하십시오. 관리자는 역할 정의를 이해해야 하며, 지원 담당자는 임시 접근 권한에 대해 알아야 하며, 엔지니어는 인증이 어디에 위치해야 하는지, 어디에 위치하지 shouldn't하는지 알아야 합니다.
그 인간层을 생략하면, 사용자가 공유된 자격증명과 백 채널 예외를 사용하여 시스템을 우회하는 기술적으로 완벽한 시스템이 될 것입니다.
보안 및 운영을 위한 최적화된 방법
A mobile team ships a Friday hotfix through a live update channel. By Monday, nobody can answer three basic questions: who approved it, which pipeline published it, and whether the engineer who triggered it still needed that level of access. That is the operational side of app access management, and it is where otherwise solid IAM designs start to break down.
인간을 인증하는 것은 단순합니다. 그러나 앱, 도구, 환경 및 책임이 변경되는 경우에 접근 권한이 정확하게 유지되는 것은 지속적인 문제입니다. Lumos는 액세스 관리를 대규모로 설명하는 논의에서 이러한 운영 부담을 잘 설명합니다. 접근 권한 관리를 대규모로Capacitor와 Electron 팀의 경우, 일반적인 IAM 지침이 거의 다루지 않는 CI 실행자, 서명 키, 데스크톱 자동 업데이트 시스템, 모바일 라이브 업데이트 채널 및 생산 데이터에 접근할 수 있는 지원 도구와 같은 압박이 나타납니다.
인간과 기계의 접근 권한을 다르게 보호하세요.
사람, pipeline 및 서비스 계정의 공유 모델은 보이지 않는 영역을 만듭니다.
인간의 접근 권한은 승인, 시간 제한 및 비즈니스 컨텍스트가 필요합니다. 기계의 접근 권한은 좁은 범위, 가능한 한 짧은 유효 기간의 자격증명 및 작업로드 사이의 경계가 강한 경우가 필요합니다. 데스크톱 릴리스를 배포하는 CI 작업은 릴리스 매니저와 동일한 권한을 상속하지 않아야 합니다. 고객 문제를 디버깅하는 지원 엔지니어는 백엔드 서비스가 내부 API를 호출하는 동일한 경로를 사용하지 않아야 합니다.
For cross-platform teams, four controls carry most of the weight:
- 분리된 배포 권한: code을 작성하고 릴리스를 승인하고 프로덕션으로 푸시하는 권한이 다르야합니다.
- pipeline 인증을 단단히 묶어라: 빌드 작업은 workflow assign 된 앱, 채널 및 환경에만 __CAPGO_KEEP_0__을 푸시해야합니다.
- 업데이트 시스템을 특권 인프라로 다루라: 시스템이 code, 자산 또는 구성 파일을 장치에 배포할 수 있다면, 접근 제어 모델에 포함시켜야합니다.
- 특권 동작을 모두 로그에 남겨라: __CAPGO_KEEP_0__은 __CAPGO_KEEP_1__ 또는 Electron을 사용하는 팀에 해당하는 부분에 들어맞습니다. signed live updates, channel-based targeting, rollback controls, 및 per-device logs를 제공합니다. IAM을 대체하지는 않습니다. IAM에 추가된 특권 표면을 관리할 수 있도록 해줍니다. 특히, 스테이징, phased rollout, 및 프로덕션 채널을 관리하는 팀이 다르다면.
Capgo fits into this part of the design for teams using Capacitor or Electron. It provides signed live updates, channel-based targeting, rollback controls, and per-device logs. That does not replace IAM. It gives you another privileged surface to govern, especially if different teams manage staging, phased rollout, and production channels.
AI agent 보안에 대한 기업 가이드 __CAPGO_KEEP_1__ 은 유용하다. 왜냐하면 agent를 실제 권한이 있는 접근 주체로 다루기 때문이다. 단순한 생산성 도구로만 다루기 때문이다.
리뷰를 연속적으로 하라. 절대적인 리뷰를 하라.
정기적인 접근 리뷰는 간단한 이유로 실패한다. 리뷰어는 거대한 스프레드 시트를 받고, 아무런 맥락도 없이 approve를 클릭하고,陈舊한 접근 권한은 또 다른 사이클 동안 살아남는다.
연속적인 리뷰가 더 나은 이유는 엔지니어링 팀이 변경하는 방식과 일치하기 때문이다. 사람들은 프로젝트를 바꾸고, 계약자들은 온-오프를 하며 pipe line은 출시 압박 동안 추가된다. 베타 사용자, 기업 테넌트, 또는緊急修정에 대한 새로운 업데이트 채널이 나타난다. 접근 권한은 그 순간에 리뷰되어야 하며, 단지 일정에 따라 리뷰되어서는 안된다.
| 리뷰 유형 | 최적의 사용 | 주의해야 할 점 |
|---|---|---|
| 이벤트 기반 리뷰 | 역할 변경, 사고, 해고, 벤더 접근 | 다음에 예정된 사이클을 기다리는 |
| 대상화된 특권 리뷰 | 제품 관리자, 청구 접근, 고객 데이터 접근 | low-risk 및 high-risk 접근을 함께 묶는 번들링 |
| 소유권 검토 | 도구 관리자는 역할 정의 및 그룹 멤버십을 확인합니다. | 유기된 그룹이 영구적으로 지속되는 것을 허용합니다. |
접근을 깨끗하게 유지하는 팀은 일반적으로 몇 가지 운영적인 일들을 일관되게 수행합니다:
- 최소 권한으로 시작합니다. 넓은 초기 승인은 영구적으로 변합니다.
- Sensitive 작업에 대한 Just-in-Time 접근을 사용합니다. 관리자 권한이 서서히 사라지고 더 이상 위험하지 않아 보입니다.
- 시스템 간에 자동으로 Deprovisioning을 수행합니다. 퇴사자에 대한 접근을 제거해야 하며, SaaS 도구, CI, 지원 콘솔, 업데이트 플랫폼과 함께 동시에 업데이트해야 합니다.
- 비활성 접근을 검토합니다. API 계정, 사용하지 않는 API 키, 그리고旧 버전의 인증 정보는 모두 드리프트의 신호입니다.
- workflow의 일부로 증거를 저장하십시오. 좋은 로그와 승인 기록은 감사 절차를 빠르게 진행할 수 있게 해줍니다. 증거가 이미 존재하기 때문입니다.
리뷰어는 접근권이 존재하는 이유, 승인자, 그리고 만료 시기를 알 수 없다면, 그 접근권은 보통 유지됩니다.
강력한 앱 접근 관리는 예술적인 정책 다이어그램보다도 실제적인 정확성을 중요시합니다. 접근 권한이 팀이 업데이트를 진행하고, pipeline을 실행하고, 고객을 지원하며, 책임을 변경하는 주간 동안도 일치하는지 확인하는 것이 중요합니다.
Enterprise App Access Checklist
다음의 엔지니어링, 보안, 또는 릴리즈 회의에서 이 체크리스트를 사용하십시오.
정책 및 관리
- 역할이 실제 직무 기능에 매핑되는지 확인하십시오. 각 역할의 존재 이유를 한 문장으로 설명할 수 있나요?
- Sensitive한 액션들이 명확하게 분리되어 있는지 확인하십시오. production 릴리즈, 고객 데이터 접근, 비용, 정책 변경 등이 하나의 관리자 역할에 통합되지 않는지 확인하십시오.
- 임시 승격이 정의되었습니다: 팀이 임시 권한 부여에 대한 표준 경로가 있습니까?
- 해고가 명확한 책임자가 있습니까: SaaS, CI, 지원 및 업데이트 시스템의 모든 곳에서 완전한 취소권을 소유해야 합니다.
기술 구현
- 인증이 중앙화되었습니다: 앱별 로그인 섬들이 정책이 분산되는 것을 피하십시오.
- 권한이 서버 측에서 살아 있습니다: 클라이언트는 자격 증명을 제시할 수 있지만 최종 정책 엔진이 아닙니다.
- 기계 식별성이 사람과 분리된 별도의 영역에서 관리되나요: CI 작업, 봇 및 통합에 대한 제어가 필요합니다.
- 업데이트 채널 및 릴리스 시스템이 권한이 있는 자산으로 처리되나요: code을 배송하는 것은 액세스 문제가 아니라 DevOps 문제만이 아님.
ongoing operations
- __CAPGO_KEEP_1__에서 고위험 액세스를 지속적으로 검토하고 있습니까: 모든 권한이 동일한 검토 주기 필요하지 않습니다.
- 권한이 승인되고 사용된 특권 액세스를 추적할 수 있나요: 감사성을 내장해야 하며 나중에 재구성하는 것이 아닙니다.
- 잘못된 계정과 사용하지 않는 권한이 제거되나요: 잠재적인 액세스는 자동화된 청소가 없으면 살아남습니다.
- 팀이 현재 모델을 설명할 수 있나요. 다섯 개의 대시보드를 열지 않고. 아니면 시스템은 이미 너무 불투명합니다.
강력한 앱 액세스 관리 프로그램은 최고의 방식으로 재미없어야합니다. 사람들은 필요한 액세스를 받습니다. 특권 액세스는 만료됩니다. 이탈이 청소 트리거입니다. 릴리스는 제어됩니다. 감사는 고고학이 아닌 것으로 멈춥니다.
팀이 Capacitor 또는 Electron 앱을 배송하고 릴리스 액세스, 업데이트 채널, 롤백 안전성에 대한 더 chặt한 제어가 필요하다면, 업데이트 채널, 롤백 안전성에 대한 더 chặt한 제어가 필요하다면, Capgo __CAPGO_KEEP_0__은 배포 스택의 일부로 평가하는 것이 가치가 있습니다. 팀에게 signed web updates를 public하는 구조화된 방법, 특정 채널을 대상으로 하며 변경 사항, 변경 위치, 장치가 변경 사항을 채택하는 방법에 대한 감사 기록을 유지하는 방법을 제공합니다.
