View a markdown version of this page

모범 사례 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

모범 사례

새로운 DevSecOps 메커니즘을 구현할 때는 코드 작성자의 다양한 소스와 코드 작성자가 권한을 부여받거나 차단될 수 있는 방법을 고려하는 것이 중요합니다. 엔지니어는 종종 이러한 소스 중 하나와만 인터페이스할 수 있습니다. 그러나 새로운 메커니즘을 도입하면 새로운 저작권 소스가 최전선에 오거나 이전에 고려하지 않은 소스의 문제를 강조할 수 있습니다. 다음 각 측면을 자세히 살펴보겠습니다.

  • 애플리케이션 팀 개발자 - 코어 애플리케이션 코드를 담당하는 개발자입니다. 필요에 따라 애플리케이션 코드를 변경하고 업데이트할 수 있는 권한이 있어야 하지만 해당 작업은 새로운 DevSecOps 메커니즘과도 일치해야 합니다.

  • 중앙 인프라 개발자 -이 팀은 클라우드 리소스, 네트워킹 및 보안과 같은 조직의 핵심 인프라를 담당합니다. 새 메커니즘이 원활하게 통합되도록 코드형 인프라(IaC) 및 배포 프로세스를 정의하는 데 관여해야 합니다.

  • 타사 및 오픈 소스 코드 기반 - 타사 라이브러리 및 오픈 소스 구성 요소의 사용이 일반적입니다. 그러나 이러한 소스는 새로운 DevSecOps 메커니즘 내에서 신중하게 관리되고 보호되어야 합니다.

  • 재사용 가능한 코드 및 아티팩트 - 재사용 가능한 코드 및 아티팩트의 생성 및 사용을 홍보하면 효율성과 일관성을 개선할 수 있지만 이러한 공유 리소스의 소유권과 거버넌스를 명확하게 정의해야 합니다.

  • 공유 리포지토리 및 기여 - 공유 리포지토리를 통해 공동 코드 작성을 활성화하는 것이 유용할 수 있지만 품질과 보안을 유지하려면 액세스, 병합 정책 및 코드 검토를 신중하게 관리해야 합니다.

  • IaC에 대한 분기 전략 - Git 방법론은 일반적인 인프라 설계 패턴과 직접 호환되지 않습니다. 인프라 관리의 고유한 문제를 수용하기 위해 IaC에 기존 분기 전략을 조정해야 할 수 있습니다. 여기에는 인프라의 상태 저장 특성, 드리프트 가능성, 라이브 환경을 변경할 때 신중한 조정을 고려하는 특수 워크플로 개발이 포함될 수 있습니다.

  • 상태 관리 - 인프라 상태를 관리하는 것은 IaC에서 매우 중요합니다. 적절한 상태 관리를 통해 실제 인프라가 정의된 코드와 일치하고 충돌 또는 의도하지 않은 변경을 방지할 수 있습니다. 원격 상태 스토리지 및 상태 잠금 메커니즘 사용과 같은 강력한 상태 관리 관행을 구현하는 것은 일관성을 유지하고 다중 사용자 환경에서 충돌을 방지하는 데 필수적입니다.

  • 보안 - IaC 및 DevSecOps의 맥락에서 보안은 인프라 수명 주기의 모든 단계에 통합되어야 합니다. 여기에는 IaC 코드 베이스 자체의 보안, 최소 권한 액세스 제어 구현, 민감한 데이터 암호화, 인프라 코드 및 결과적으로 배포된 리소스의 취약성에 대한 정기적인 스캔이 포함됩니다. 자동화된 보안 검사 및 규정 준수 검증을 지속적 통합 및 지속적 전달(CI/CD) 파이프라인에 통합하여 보안 모범 사례가 일관되게 적용되도록 해야 합니다.

서로 다른 팀을 효과적으로 지원하고 지원하는 DevSecOps 메커니즘을 설계하려면 코드 작성의 모든 잠재적 소스를 식별하고 요구 사항과 과제를 이해해야 합니다. 이 접근 방식은 조직 전체에서 새로운 메커니즘을 원활하게 구현하고 채택하는 데 도움이 됩니다.

DevSecOps 메커니즘 설계는 단순한 기술적 측면을 뛰어 넘습니다. DevSecOps 메커니즘의 설계 및 구현은 광범위한 영향을 미칩니다. 담당 팀은 문화적, 조직적, 인적 요소를 신중하게 고려해야 합니다. 이 고려 사항은 솔루션이 기술 요구 사항을 충족할 뿐만 아니라 모든 이해관계자를 위한 긍정적이고 생산적이며 매력적인 작업 환경을 조성하는 데 도움이 됩니다. 장기적인 성공과 직원 만족도를 위해서는 적절한 균형을 유지하는 것이 중요합니다.

DevSecOps 메커니즘의 설계 및 배포와 관련된 다음 시나리오를 고려하세요.

  • 개발자와 유지 관리자 간의 차이 확대 - 개발자가 솔루션을 신속하게 제공할 수 있도록 시스템을 구현하면 유지 관리자의 명백한 작업 부족을 실수로 강조할 수 있습니다. 유지 관리자는 개발자 직함을 가진 개인이지만 day-to-day 책임은 기존 애플리케이션의 지원 및 안정성으로 전환되었습니다. 유지 관리자의 새로운 기여도 부족은 과거에는 잘 보이지 않았을 수 있습니다. 이러한 상황으로 인해 조직은 이러한 유지 관리 담당자의 중요한 지식과 전문 지식을 소중하게 여기고, 잠재적으로 분노와 사기 저하를 초래할 수 있습니다.

  • 지나치게 관리되는 솔루션으로 개발자 제거 - 개발자가 사용하기에 번거로운 고도로 관리되는 DevSecOps 솔루션을 구축하면 유지 관리자를 유치할 수 있습니다. 그러나 솔루션은 조직이 혁신을 주도하는 데 필요한 인력을 제거할 수 있습니다. 개발자가 애플리케이션 및 프로그래밍 언어 외에도 독점 CI/CD 메커니즘을 학습하도록 강요하는 것은 채택에 상당한 장벽이 될 수 있습니다. 고도로 관리되는 DevSecOps 솔루션은 유능한 개발자에게 불리한 요인이 될 수 있습니다.

  • 문화적 비호환성 및 중단 위험 - 조직의 기존 작업 방식과 문화적으로 호환되지 않는 DevSecOps 메커니즘을 구현하면 상당한 마찰과 저항이 발생할 수 있습니다. 메커니즘의 접근 방식(예: 권고에 비해 규범적)이 조직의 문화와 일치하지 않는 경우 채택되지 않을 수 있습니다. 따라서 일부 이해관계자는 좌절감을 느끼고 조직이 불필요한 관료성을 향해 나아가고 있다고 생각할 수 있습니다.