개발자에게 이론뿐 아니라 실제 접근 제어 정책이 필요한 이유
코드를 배포하거나 유지 관리하는 경우 pipeline아티팩트 레지스트리 관리와 같은 작업에는 이론 이상의 것이 필요합니다. 취약하거나 명확하게 정의되지 않은 접근 제어 정책은 저장소 변조를 초래할 수 있습니다. CI/CD 남용, 그리고 자격 증명 유출DevSecOps는 단순히 숨겨진 권한 설정이 아니라 실질적인 강제 집행을 요구합니다.
코드 저장소 전반에 걸쳐 접근 제어 정책을 효과적으로 관리하려면, CI/CD pipelines아티팩트 레지스트리를 비롯한 다양한 관리 환경에서 많은 팀은 Xygeni와 같은 자동화된 정책 시행 도구를 활용합니다. Xygeni는 역할, 권한 및 정책 준수 여부를 지속적으로 모니터링하여 권한 변동, 무단 접근 및 수동 재정의를 방지하고, 의무적 접근 제어 이론을 실질적인 행동으로 전환하도록 지원합니다.
접근 제어는 소스 코드를 직접 잠그고, 빌드를 안전하게 보호하며, 프로덕션 환경을 보호합니다. pipeline개발자가 제어를 우회하거나 서비스 계정에 광범위한 권한이 부여되면 보안 침해의 위험이 열립니다. 따라서 필수 접근 제어, MAC 접근 제어 및 기타 모델을 이해하는 것이 매우 중요합니다.
개발자가 알아야 할 접근 제어 정책 유형
접근 제어 정책은 크게 세 가지 범주로 나뉘며, 각 범주는 서로 다른 방식으로 적용됩니다. CI/CD 워크플로. 이해를 돕기 위해 간단하게 나란히 비교해 보겠습니다.
| 모델 | 접근 권한은 누가 관리하나요? | 일반적인 사용 사례 CI/CD | 위험 수준 |
|---|---|---|---|
| DAC(재량적 접근 제어) | 리소스 소유자(개발자, 관리자) | 저장소 또는 레지스트리 접근 권한의 수동 공유 | 높음 (인적 오류) |
| RBAC(역할 기반 접근 제어) | 시스템은 역할별로 권한을 할당합니다. | GitHub 브랜치 보호, 사용자 역할 기반 CI 작업 접근 권한 | 중간 수준 (잘못 구성된 역할) |
| MAC(강제 접근 제어) | 시스템 정책에 의해 시행됨 | 누가 결과물을 게시하거나 코드를 배포할 수 있는지를 강제합니다. | 낮음 (정책이 사용자 의도를 무시함) |
MAC와 RBAC의 차이점을 명확히 설명하겠습니다. CI/CD 문맥
역할 기반 접근 제어를 혼동하기 쉽습니다.RBAC특히 MAC 접근 제어와 같은 필수 접근 제어가 적용되는 경우 CI/CD 환경. 동안 CI/CD GitHub나 GitLab 같은 플랫폼은 RBAC(역할 기반 접근 제어)를 사용하여 역할과 권한(예: 누가 병합 또는 배포할 수 있는지)을 관리하는데, 이는 근본적으로 역할 기반 접근 제어이지 진정한 MAC(사용자 계정 제어) 접근 제어는 아닙니다.
RBAC(역할 기반 접근 제어)를 사용하면 역할(개발자, 관리자 등)에 따라 권한을 할당할 수 있지만, 이러한 권한은 여전히 사용자가 제어하고 수정할 수 있습니다. 잘못된 구성이나 권한 남용은 흔히 발생하는 위험입니다.
반면, 강제 접근 제어(MAC 접근 제어)는 시스템 또는 인프라 수준에서 적용됩니다. 관리자를 포함한 사용자는 이를 무시할 수 없습니다. MAC 접근 제어는 플랫폼에 내장된 정책으로 생각할 수 있습니다. 예를 들어 클라우드 제공업체(AWS IAM, GCP IAM 등)의 IAM 정책이나 SELinux 또는 AppArmor와 같은 운영 체제 수준의 적용 도구가 있습니다. 이러한 경우, 미리 정의되어 있고 우회할 수 없는 규칙이 충족될 때만 접근이 허용됩니다.
In CI/CD많은 도구들이 엄격하게 제한된 IAM 역할이나 리소스별 권한을 통해 MAC 접근 제어 동작을 시뮬레이션하지만, 이는 완전한 강제 접근 제어가 아닙니다. 진정한 강제 접근 제어는 애플리케이션 계층 아래, 즉 운영 체제, 네트워크 또는 클라우드 인프라 수준에서 제어가 이루어져야 하며, 이러한 수준에서는 접근이 사람의 설정이 아닌 변경 불가능한 접근 제어 정책에 의해 관리되어야 합니다.
RBAC (역할 기반 액세스 제어)
RBAC는 권한을 "개발자", "유지보수 담당자", "릴리스 관리자"와 같은 정의된 역할에 매핑합니다. 이를 통해 GitHub와 같은 도구에서 관리가 간소화됩니다. GitLab사용자별로 설정을 구성하는 대신, 사용자에게 역할을 할당하고 시스템이 규칙을 적용하도록 하십시오.
이를 통해 지정된 역할의 사용자만 중요 디렉터리의 변경 사항을 승인할 수 있습니다.
GitLab 역할 설정: 설정 > 멤버에서 프로젝트 액세스 권한을 구성하세요.
- 개발자: 기능 브랜치로 푸시할 수 있습니다.
- 관리자: 보호된 브랜치로 병합할 수 있습니다.
- 손님: 읽기 전용 액세스.
GitHub Actions 워크플로 RBAC 예시:
필수 액세스 제어 (MAC)
강제 접근 제어(MAC 접근 제어)는 사용자와 관리자가 재정의할 수 없는 엄격한 시스템 수준 규칙을 적용합니다. MAC 접근 제어를 사용하십시오. 핵심 자원에 대한 읽기, 쓰기 또는 실행 권한을 엄격하게 통제합니다.
예: Google 아티팩트 레지스트리 정책(간소화된 YAML)
예: Amazon ECR 정책(간소화된 YAML 형식)
수동 재정의의 위험성과 MAC이 이를 방지하는 방법
RBAC와 관련된 가장 큰 위험 중 하나는 다음과 같습니다. DAC 모델 의도적이든 우발적이든 수동으로 권한을 재정의할 가능성이 있습니다. 예를 들어 관리자나 개발자가 보호된 레지스트리에 직접 아티팩트를 업로드하거나 정의된 접근 제어 정책을 벗어나 과도한 권한을 부여할 수 있습니다. 이러한 행위는 취약점을 초래하거나 규정 준수에 허점을 만들 수 있습니다.
강제 접근 제어(MAC 접근 제어)는 관리자를 포함한 어떤 사용자도 우회할 수 없는 시스템 수준 정책을 적용하여 이러한 정책 변경을 방지합니다. 접근 제어는 시스템 수준 정책을 강제함으로써 이러한 문제를 해결합니다.cis이온은 인프라에 내장된 변경 불가능한 규칙(예: 클라우드 IAM 정책 또는 OS 수준 보안 모듈)에 의해 관리됩니다. 즉, 다음과 같습니다.
- Mac 접근 제어 정책에서 아티팩트 업로드를 거부하는 경우, 관리자는 수동으로 레지스트리에 아티팩트를 업로드할 수 없습니다.
- 사용자는 정의된 접근 제어 정책 범위를 벗어나 권한을 상승시키거나 권한을 변경할 수 없습니다.
- 자동화 CI/CD pipelines는 할당된 권한 내에서만 엄격하게 실행되어 범위 확장을 방지합니다.
수동 접근 제한을 제거함으로써, 강제 접근 제어는 RBAC 또는 DAC 단독 사용보다 더 강력하고 안정적인 보안을 보장합니다.
2.4 임의 접근 제어(DAC)
DAC는 리소스 소유자가 수동으로 권한을 할당할 수 있도록 해줍니다. 유연하지만 위험 부담도 있습니다. 잘못된 공유 하나로 저장소 전체가 위험에 처할 수 있습니다. DAC는 "소유자가 권한을 갖고 있으니, 누가 접근할 수 있는지 직접 결정하세요"라는 원칙에 따라 작동합니다.
예시: a 개발자가 외부 협력자를 초대하고 저장소에 대한 쓰기 권한을 부여합니다. 협력자는 보안에 취약한 코드를 저장소에 직접 푸시합니다. DEV 분기.
In CI/CDDAC는 개발자가 정의된 액세스 제어 정책 외부에서 콘솔을 통해 임시 팀원에게 프로덕션 배포 액세스 권한을 수동으로 부여하는 것처럼 보일 수 있습니다.
실제 환경에 적합한 접근 제어 정책을 선택하는 방법 Pipelines
Git에서의 접근 제어
RBAC를 활용하여 기여자, 유지 관리자 및 릴리스 역할을 관리합니다. 보호된 브랜치에 대한 병합 권한을 잠급니다. 서명된 버전을 요구합니다. commit보호 조치를 우회할 수 있는 사람을 제한합니다.
예시: GitHub 브랜치 보호 규칙
- 요구 pull request 합병 전 검토.
- 오래된 것을 기각합니다 pull request 새로운 승인 commits가 밀려납니다.
- 서명 필요 commits.
- 운영상 중요한 저장소에는 DAC를 사용하지 마세요. 쓰기 권한을 함부로 부여하지 마세요.
Pipeline 시행
필수 접근 제어 시스템을 구축하십시오. pipeline견고한 Mac 접근 제어 모델은 CI 작업에 필요한 권한만 부여합니다.
- 환경별로 비밀 정보를 분리하세요.
- 환경별로 고유한 토큰을 사용하십시오.
- 수동 실행이 프로덕션에 영향을 미치는 것을 방지합니다.
예: CI 작업이 스테이징과 프로덕션 환경에서 배포 토큰을 재사용하여 실수로 테스트 코드를 실제 운영 환경에 배포했습니다.
토큰 범위를 제어하기 위해 Mac 접근 제어 규칙을 추가하세요.
비밀 범위 지정 예시: 환경별 토큰 사용
환경별로 비밀 범위를 적절하게 설정하는 것이 매우 중요합니다. 우발적이거나 악의적인 환경 간 접근을 방지합니다. 예를 들어, 개발 환경용 배포 토큰은 프로덕션 환경 배포에 절대 사용해서는 안 됩니다.
다음은 액세스 제어 정책 기반 제어를 통해 GitHub Actions에서 비밀 키 사용을 격리하는 방법입니다.
이는 다음을 강제합니다:
- 오직 개발자 역할은 개발 토큰을 사용하여 배포를 트리거할 수 있습니다. DEV 분기.
- 오직 릴리스 관리자 해당 역할은 prod 토큰을 사용하여 프로덕션 환경에 배포할 수 있습니다. 본관 분기.
이처럼 범위가 제한된 비밀 키 사용은 토큰 유출이 여러 환경으로 확산될 위험을 줄여줍니다. 최소 권한을 시행합니다 CI/CD pipelines 강력한 접근 제어 정책을 따릅니다.
아티팩트 접근 제어
필수 접근 제어를 사용하여 아티팩트 레지스트리를 안전하게 보호하십시오. CI/CD 게시 작업은 개별 개발자가 아닌 시스템에서 처리해야 합니다.
RBAC(역할 기반 접근 제어)를 사용하여 특정 레지스트리에서 패키지를 가져올 수 있는 팀을 정의하세요. 개발자는 프로덕션 패키지에 대한 읽기 권한만 필요할 수 있습니다.
개발 워크플로우에서 흔히 발생하는 접근 제어 오류
지나치게 관대한 저장소 접근 권한
문제 : 너무 많은 사용자에게 저장소에 대한 쓰기/관리자 권한을 부여하는 경우.
어떻게 일어나는가: 팀 구성원이 권한 검토 없이 승진하거나 새로 추가되어 역할이 불필요하게 복잡해집니다.
공격자 취약점: 공격자들은 탈취한 계정 정보나 소셜 엔지니어링 기법을 이용하여 이러한 계정들을 표적으로 삼습니다. 계정에 침투한 후에는 악성 코드나 백도어를 삽입하거나, 흔적을 숨기기 위해 기록을 삭제할 수 있습니다.
개발 환경과 운영 환경 간 권한 공유
문제 : 개발 및 프로덕션을 허용합니다 pipelines 공유 권한.
어떻게 일어나는가: 팀은 여러 환경에서 동일한 배포 토큰 또는 CI 서비스 계정을 재사용합니다.
공격자 취약점: 개발 환경 침해는 공격자에게 프로덕션 환경에 대한 접근 권한을 부여합니다. 필수 접근 제어 특정 환경에 권한을 부여함으로써 이를 방지할 수 있습니다.
수동 아티팩트 업로드
문제 : 운영 레지스트리에 수동으로 아티팩트를 업로드할 수 있도록 허용합니다.
어떻게 일어나는가: 개발자들이 우회합니다 pipeline임시방편이나 단기적인 해결책을 의미합니다.
공격자 취약점: 해킹당한 개발자 컴퓨터는 모든 보안 조치를 우회하여 악성코드를 아티팩트 저장소에 직접 업로드할 수 있습니다. CI/CD 보안 검사.
레지스트리 정책 남용 위험: 수동으로 아티팩트를 게시하는 것은 소프트웨어 공급망에 심각한 공격 표면을 만듭니다. 공격자들은 이러한 허점을 악용합니다. 액세스 제어 정책 악성 코드는 신뢰할 수 있는 패키지나 컨테이너 이미지에 삽입되어 광범위한 하위 시스템 침해를 초래할 수 있습니다. 최근 소프트웨어 공급망 사고는 규제되지 않은 아티팩트 업로드가 어떻게 수많은 사용자와 시스템에 영향을 미치는 심각한 보안 침해로 빠르게 확산될 수 있는지를 보여줍니다.
예시: anpm 레지스트리에 대한 완전한 접근 권한을 가진 인턴이 실수로 불안정 버전을 게시했습니다. 만약 공격자가 해당 인턴의 컴퓨터를 해킹했다면, 악성코드를 게시했을 수도 있습니다.
강력한 접근 제어를 시행하기 위한 실질적인 단계
- 역할에 정확한 권한을 매핑하고, 모든 사용자에게 단일 역할을 부여하는 방식을 버리세요.
- 액세스 제어 정책 검사를 자동화하세요 CI/CD pipelines
- 필수 접근 제어를 통해 레지스트리를 안전하게 보호하세요.
- 중요 시스템에 대한 접근을 지속적으로 기록하고 모니터링합니다.
- 접근 제어 정책을 코드처럼 다루세요. 사소한 실수라도 악용될 수 있습니다.
Xygeni의 역할: DevOps 워크플로우에서 액세스 정책을 시행하고 모니터링합니다.
제니 이 솔루션은 DevSecOps 환경에서 발생하는 실제적인 접근 제어 정책 시행 문제를 해결함으로써 필수 접근 제어를 이론에서 실행으로 옮길 수 있도록 지원합니다. pipelines.
- Git 접근 권한 과다 문제 해결: Xygeni는 검토되지 않은 역할 할당이나 누락된 브랜치 보호와 같은 RBAC(역할 기반 접근 제어) 위반 사항을 지속적으로 모니터링합니다. 접근 제어 정책이 정의된 규칙에서 벗어나면 경고를 보내고, 의도치 않은 병합이나 악의적인 PR(풀 리퀘스트)을 방지하기 위해 시정 조치를 시행합니다.
- 봉쇄 CI/CD Pipelines: CI 작업은 때때로 의도했던 것보다 더 넓은 범위에서 실행될 수 있습니다. Xygeni는 이러한 경우를 감지합니다. CI/CD 직무가 할당된 역할 범위를 벗어나 요청하거나 작업을 수행하는 경우, 업무 범위 확장 및 권한 남용을 실시간으로 식별합니다. 이는 내부 MAC 접근 제어 원칙을 강화하는 데 도움이 됩니다. pipeline직무의 정체성과 목적에 접근 권한을 엄격하게 연결함으로써 가능합니다.
- 아티팩트 게시 제어 강화: 개발자들이 여전히 아티팩트나 이미지를 수동으로 업로드하는 경우, Xygeni는 이를 차단합니다. 레지스트리 수준의 필수 접근 제어를 적용하여 검증된 파일만 접근할 수 있도록 합니다. pipeline 사용자가 직접 아티팩트를 게시할 수 있습니다. 더 이상 사람이 직접 프로덕션 레지스트리에 파일을 업로드할 필요가 없습니다.
- 접근 모니터링 및 이상 징후 표시: Xygeni를 사용하면 누가 언제 어떻게 무엇에 접근했는지에 대한 가시성을 확보할 수 있습니다. Xygeni는 비밀 정보 사용량, 저장소 접근 및 레지스트리 상호 작용을 지속적으로 추적하여 비정상적인 동작을 감지하고, 잘못된 구성을 표시하며, 사고 후 분석을 지원합니다.
하단 라인 : Xygeni는 액세스 제어 정책에 자동화 및 강제 기능을 제공하여 DevOps 환경을 안전하게 유지하면서도 속도를 저하시키지 않습니다.
그러므로 접근 제어를 다음과 같이 취급하십시오. Code Security
배포 권한이나 인프라 접근 권한이 있는 사람은 누구나 의도적이든 아니든 앱을 망가뜨릴 수 있습니다. 그렇기 때문에 강력한 접근 제어 정책은 선택 사항이 아닙니다. RBAC를 사용하여 역할을 적절하게 위임하십시오. 중요 시스템에는 필수 접근 제어를 적용하십시오. 프로덕션 경로에서는 DAC를 완전히 사용하지 마십시오. 접근 제어 정책을 시스템에 통합하세요 DevSecOps 모범 사례. 자동화하고, 모니터링하고, 시행하십시오.
TL; DR잘 시행되는 접근 제어 정책은 코드베이스, 산출물 및 인프라를 자동으로 더 안전하게 만들어 줍니다.
