모범 사례

새로운 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 메커니즘을 구현하면 상당한 마찰과 저항이 발생할 수 있습니다. 메커니즘의 접근 방식(예: 권고에 비해 규범적)이 조직의 문화와 일치하지 않는 경우 채택되지 않을 수 있습니다. 따라서 일부 이해관계자는 좌절감을 느끼고 조직이 불필요한 관료성을 향해 나아가고 있다고 생각할 수 있습니다.