혁신 보안

혁신은 디지털 시대에 조직의 생혈이며 활성화되고 보호되어야 합니다. 혁신 보안은 사이버 공격으로부터 혁신 프로세스와 데이터를 보호합니다. 디지털 시대의 혁신은 릴리스 사이에 수 개월 또는 수 년이 걸릴 수 있는 기존의 폭포식 모델 출하 일정을 기다리지 않고 DevOps 또는 DevSecOps 방법을 사용하여 애플리케이션을 개발하여 빠르게 혁신하는 형태를 취합니다.

새로운 기능과 애플리케이션을 개발하려면 세 가지 요구 사항 유형을 충족해야 합니다.

• 비즈니스 개발(Dev): 빠르게 진화하는 경우가 많은 비즈니스 및 사용자 요구 사항을 애플리케이션이 충족해야 합니다.
• 보안(Sec): 빠르게 진화하는 공격자의 공격에 대해 애플리케이션 복원력이 있어야 하며 보안 방어에 혁신을 활용해야 합니다.
• IT 운영(Ops): 애플리케이션이 안정적이고 효율적으로 수행되어야 합니다.

이 세 가지 요구 사항을 함께 병합하고 공유 문화를 만드는 것이 매우 중요하지만 어려운 경우가 많습니다. 개발, IT 및 보안 팀의 리더는 이러한 변화를 주도하기 위해 협력해야 합니다. 자세한 내용은 리더십 리더십의 필수 요소: 문화 혼합을 참조하세요.

다음 비디오를 시청하여 안전하고 신속한 혁신을 위한 DevSecOps 방법에 대해 자세히 알아봅니다.

DevSecOps란?

기술 혁신은 개발과 운영을 DevOps 프로세스로 결합하는 신속한 간결하고 민첩한 개발 방식의 맥락에서 전개되는 경우가 많습니다. 이러한 프로세스에 보안을 통합하는 것이 혁신 프로세스, 조직의 성장 및 조직의 기존 자산에 대한 위험을 완화하는 데 중요하다는 것을 터득해왔습니다. 보안을 프로세스에 통합하면 DevSecOps 프로세스가 만들어집니다.

초기 단계에 보안 설계

조직이 DevOps 및 기타 신속한 혁신 방법론을 채택하는 경우 보안은 조직 및 조직의 개발 프로세스라는 구조 전체에 걸쳐 짜여진 실과 같아야 합니다. 프로세스 후반에 보안을 통합하면 비용이 많이 들고 수정이 어렵습니다.

타임라인에서 보안을 왼쪽으로 이동하여 서비스 및 제품의 구상, 디자인, 구현 및 운영에 보안을 통합합니다. 개발 팀이 DevOps로 이동하고 클라우드 기술을 도입하는 경우 보안은 이러한 변화의 일부가 되어야 합니다.

폭포 모델에서 보안은 일반적으로 개발이 완료된 후 품질 관문이었습니다.

DevOps는 운영 팀을 포함하도록 기존 개발 모델(사람, 프로세스 및 기술)을 확장했습니다. 이러한 변화는 개발 팀과 운영 팀이 분리되어 발생하는 마찰이 줄여줍니다. 마찬가지로 DevSecOps는 DevOps를 확장하여 개별적인 또는 이질적인 보안 팀의 마찰을 줄여줍니다.

DevSecOps는 아이디어 시작부터 구상, 아키텍처 디자인, 반복적인 애플리케이션 개발 및 운영에 이르는 DevOps 수명 주기의 모든 단계에 보안을 통합하는 것입니다. 팀은 혁신 속도, 안정성 및 보안 복원력의 목표에 동시에 맞춰 단결해야 합니다. 팀은 서로의 필요를 상호 이해하고 존중하는 마음으로 출처가 무엇이든 가장 중요한 문제를 먼저 해결해야 합니다.

클라우드 채택 프레임워크 구성 방법론은 organization DevSecOps 구조에 대한 추가 컨텍스트를 제공합니다. 자세한 내용은 애플리케이션 보안 및 DevSecOps 기능 이해를 참조하세요.

왜 DevSecOps인가?

DevOps는 민첩성을, DevSecOps는 보안 민첩성을 제공합니다.

지구상의 거의 모든 조직은 혁신을 통해 경쟁 우위를 확보하기 위해 소프트웨어 개발을 모색합니다. DevOps 프로세스 보안은 조직의 성공에 매우 중요합니다. 사용자 지정 애플리케이션에 대한 이러한 변화에 공격자들이 주목하고 있으며 이들이 공격하는 동안 사용자 지정 애플리케이션에 대한 공격이 늘어나고 있습니다. 이러한 신규 애플리케이션은 마켓플레이스에서 아직 상품화되지 않은 소중한 새 아이디어가 포함된 귀중한 지적 재산의 풍부한 소스인 경우가 많습니다.

이 혁신을 보호하려면 조직이 개발 프로세스와 애플리케이션을 호스트하는 인프라 모두에서 잠재적인 보안 약점과 공격을 해결해야 합니다. 이 방법은 클라우드와 온-프레미스 모두에 적용됩니다.

공격자는 다음과 같은 상황에서 약점을 악용할 수 있습니다.

• 개발 프로세스: 공격자는 애플리케이션 디자인 프로세스에서 약점을 찾을 수 있습니다(예: 통신에 사용하는 암호화가 없거나 약한 경우). 또는 공격자가 디자인 구현에서 약점을 찾을 수도 있습니다. 예를 들어 코드가 입력의 유효성을 검사하지 않고 SQL 주입과 같은 일반적인 공격을 허용하는 경우입니다. 또한 공격자가 코드에 백도어를 삽입할 수 있습니다. 그러면 나중에 돌아와서 귀사의 환경이나 고객 환경을 악용할 수 있습니다.
• IT 인프라: 개발 프로세스가 호스트되는 엔드포인트 및 인프라 요소를 공격자가 표준 공격을 사용하여 손상시킬 수 있습니다. 공격자가 훔친 자격 증명이나 맬웨어를 사용하여 환경의 다른 부분에서 개발 인프라에 액세스하는 다단계 공격을 수행할 수도 있습니다. 소프트웨어 공급망 공격의 위험으로 인해 다음 두 가지 모두에 대해 보안을 프로세스에 통합하는 것이 중요합니다.
• 조직 보호: 소스 코드 공급망의 악성 코드 및 취약성으로부터
• 고객 보호: 애플리케이션 및 시스템의 보안 문제로부터(조직에 대한 평판 손상, 책임 또는 기타 부정적인 비즈니스 영향을 초래할 수 있음)

DevSecOps 여정

대부분의 조직에서 주어진 워크로드 또는 애플리케이션에 대한 DevOps 또는 DevSecOps는 실제로 2단계 프로세스입니다. 아이디어가 먼저 안전한 공간에서 배양된 다음, 나중에 프로덕션으로 릴리스되고 반복적이고 지속적으로 업데이트됩니다.

이 다이어그램은 이러한 종류의 혁신 팩터리 방식의 수명 주기를 보여줍니다.

보안 혁신은 다음 두 단계에 대한 통합된 접근 방식입니다.

• 아이디어 배양 - 초기 아이디어가 구축되고 검증되며 초기 프로덕션에 사용하기 위해 준비되는 단계입니다. 이 단계는 새로운 아이디어로 시작하여 첫 번째 프로덕션 릴리스가 다음에 대한 MVP(최소 실행 가능 제품) 기준을 충족할 때 종료됩니다.
  • 개발: 최소한의 비즈니스 요구 사항을 기능이 충족합니다.
  • 보안: 프로덕션 사용을 위한 규정 준수, 보안 및 안전 요구 사항을 기능이 충족합니다.
  • 운영: 프로덕션 시스템이 되기 위한 최소한의 품질, 성능 및 지원 가능성 요구 사항을 기능이 충족합니다.
• DevOps: 이 단계는 지속적인 혁신과 개선을 가능하게 하는 애플리케이션 또는 워크로드의 지속적인 반복 개발 프로세스입니다.

리더십의 필수 요소: 문화 혼합

이 세 가지 요구 사항을 충족하려면 모든 팀 구성원이 모든 유형의 요구 사항을 가치 있게 여기고 공통 목표를 향해 협업할 수 있도록 세 가지 문화를 함께 병합해야 합니다.

이러한 문화와 목표를 진정한 DevSecOps 방식으로 통합하는 것은 어려울 수 있지만 투자할만한 가치가 있습니다. 많은 조직이 독립적으로 작업하는 개발 팀, IT 운영 팀, 보안 팀 사이에서 높은 수준의 비정상적 마찰을 경험하여 다음과 같은 문제를 만들고 있습니다.

• 가치 전달 지연 및 민첩성 저하
• 품질 및 성능 문제
• 보안 문제

몇 가지 문제가 있는 것은 정상적이고 새로운 개발 시 예상되기도 하지만, 팀 사이의 마찰은 문제의 수와 심각성을 상당히 키우는 경우가 많습니다. 마찰은 종종 한두 팀이 정치적 이점을 갖고 다른 팀의 요구 사항을 반복적으로 무시하기 때문에 발생합니다. 무시한 문제의 시간이 지나면서 그 양과 심각성이 커집니다. 해결하지 않은 채로 두면 이러한 역학 관계는 DevOps에서 더욱 악화될 수 있습니다. 비즈니스 요구 사항 및 고객 선호도의 급속한 변화를 충족하기 위해 의사 결정 속도가 빨라지기 때문입니다.

이러한 문제를 해결하려면 리더십이 지원하는 dev, sec 및 ops 요구 사항을 중시하는 공유 문화를 만들어야 합니다. 이런 방식을 통해 보안, 운영 안정성을 개선하든 또는 중요한 비즈니스 기능을 추가하든 팀이 더 잘 협력하고 주어진 스프린트에서 가장 시급한 문제를 해결할 수 있습니다.

리더십 기술

다음 핵심 기술은 리더십이 공유 문화를 구축하는 데 도움이 될 수 있습니다.

1. 아무도 모든 논쟁에서 이길 수 없음: 리더는 한 가지 사고 방식이 모든 결정을 지배하지 않도록 해야 합니다. 불균형을 유발하여 비즈니스에 부정적인 영향을 미칠 수 있기 때문입니다.

2. 완벽이 아닌 지속적인 개선을 기대: 리더는 지속적인 개선과 지속적인 학습에 대한 기대치를 설정해야 합니다. 성공적인 DevSecOps 프로그램 구축은 하룻밤 사이에 이루어지지 않습니다. 점진적인 진행을 통해 계속되는 여정입니다.

3. 공통 관심사와 고유한 개인 가치를 모두 높이 사기: 팀원은 공동의 결과를 위해 함께 노력하고 있으며 각 개인은 타인이 할 수 없는 것을 수행한다고 느낄 수 있도록 합니다. 모든 요구 사항 유형은 동일한 비즈니스 가치를 생성하고 보호하는 것입니다. 개발은 새로운 가치를 창출하기 위해 노력하는 반면, 운영 및 보안은 다양한 위험 시나리오로부터 그 가치를 보호하고 보존하려고 노력합니다. 조직 전체에서 모든 수준의 리더는 이러한 공통성을 전달하고 즉각적 및 장기적 성공을 위해 모든 유형의 요구 사항을 충족하는 것이 얼마나 중요한지 알려야 합니다.

4. 공유 이해 개발: 팀원 모두 다음 사항에 대한 기본적인 이해가 있어야 합니다.

   • 비즈니스 긴급도: 팀은 위험에 처한 수익에 대해 명확한 그림이 있어야 합니다. 여기에는 현재 수익(서비스가 오프라인 상태인 경우)과 애플리케이션 및 기능 제공 지연으로 영향을 받을 잠재적 미래 수익이 포함되어야 합니다. 리더십 관련자의 신호를 직접 기반으로 해야 합니다
   • 가능성이 있는 위험 및 위협: 위협 인텔리전스 팀 입력을 기반으로(있는 경우) 팀은 애플리케이션 포트폴리오가 직면할 가능성 있는 위협에 대한 감각을 형성해야 합니다.
   • 가용성 요구 사항: 팀은 필수 작동 시간, 애플리케이션의 예상 수명, 문제 해결 및 유지 관리 요구 사항(예: 온라인 서비스 중 패치 적용)과 같은 운영 요구 사항을 공유해야 합니다.

5. 원하는 행동을 보여주고 모범을 보이기: 리더는 팀에서 원하는 행동을 공개적으로 모델링해야 합니다. 예를 들어, 겸손을 보여주고, 학습에 집중하며, 다른 분야를 소중히 여깁니다. 또 다른 예는 개발 관리자가 보안 및 고품질 애플리케이션의 가치에 대해 언급하거나 보안 관리자가 신속한 혁신 및 애플리케이션 성능의 가치에 대해 언급하는 것입니다.

6. 보안 마찰 수준 모니터링: 본래 보안은 프로세스 속도를 저하시키는 마찰을 만듭니다. 보안으로 인해 발생하는 마찰의 수준과 유형을 리더가 모니터링하는 것이 중요합니다.

   • 정상적인 마찰: 운동을 하면 근육이 강화되듯이, DevOps 프로세스에 적절한 수준의 보안 마찰을 통합하면 적시에 비판적 사고를 하도록 하여 애플리케이션을 강화할 수 있습니다. 팀이 보안을 개선하기 위해 학습하고 이러한 학습을 사용한다면(예: 공격자가 애플리케이션을 손상시키려는 이유와 방법을 고려하여 중요한 보안 버그를 찾아서 수정하면) 제대로 진행되고 있는 것입니다.
   • 비정상적 마찰: 보호하는 것보다 방해하는 가치가 더 많은 마찰에 주의합니다. 이러한 상황은 도구에서 생성된 보안 버그에 가양성(예: 거짓 경보)이 높거나, 문제를 수정하기 위한 보안 노력이 공격의 잠재적 영향을 넘어서는 경우에 자주 발생합니다.

7. 보안을 예산 계획에 통합: 보안 예산이 보안에 대한 다른 투자에 비례하여 할당되도록 합니다. 이벤트 예산에 물리적 보안이 표준으로 포함되는 콘서트와 같은 물리적 이벤트와 유사합니다. 일부 조직에서는 보안 모범 사례의 일관된 적용을 보장하기 위해 일반적으로 총 보안 비용의 10%를 할당합니다.

8. 공유 목표 설정: 애플리케이션 워크로드의 성능 및 성공 메트릭이 개발, 보안 및 운영 목표를 반영하도록 합니다.

참고

전체 조직이든 특정 프로젝트나 애플리케이션이든 구매를 극대화하기 위해 여러 팀이 이러한 공유 목표를 공동으로 만드는 것이 이상적입니다.

DevSecOps MVP 식별

아이디어에서 생산으로 넘어가는 과정에서 기능이 각 요구 사항 유형에 대해 최소 요구 사항 또는 MVP(최소 실행 가능 제품)를 충족하는지 확인하는 것이 중요합니다.

• 개발자(dev)는 사용자, 고객 및 비즈니스 리더의 기대를 충족시키는 기능을 신속하게 제공하기 위한 비즈니스 요구를 나타내는 데 집중합니다. 기능이 조직의 성공에 도움이 되는지 확인하기 위한 최소 요구 사항을 파악합니다.
• 보안(sec)은 규정 준수 의무를 준수하고 조직의 리소스에서 불법적인 이익을 지속적으로 추구하는 공격자로부터 방어하는 데 중점을 둡니다. 규정 준수 요구 사항을 충족하고 보안 태세를 유지하며 보안 작업이 활성 공격을 신속하게 감지하고 대응할 수 있도록 하기 위한 최소 요구 사항을 파악합니다.
• 운영(ops)은 성능, 품질 및 효율성에 중점을 두고 워크로드가 장기적으로 계속해서 가치를 제공할 수 있도록 하는 데 중점을 둡니다. 가까운 장래에 대규모 아키텍처 또는 디자인 변경 없이 워크로드를 수행하고 지원할 수 있도록 최소 요구 사항을 파악합니다.

MVP에 대한 정의는 시간이 지나면서, 팀 자체 경험을 통해 그리고 다른 조직을 통해 함께 학습하기 때문에 다양한 워크로드 유형에 따라 달라질 수 있습니다.

보안을 프로세스에 기본적으로 통합

보안 요구 사항은 기존 프로세스 및 도구와 기본적으로 통합하는 데 중점을 두어야 합니다. 예를 들어 다음과 같습니다.

• 위협 모델링 같은 디자인 작업은 디자인 단계에 통합되어야 합니다.
• 보안 검사 도구는 Azure DevOps, GitHub 및 Jenkins와 같은 CI/CD(연속 통합 및 지속적인 업데이트) 시스템에 통합되어야 합니다.
• 보안 문제는 다른 버그와 동일한 버그 추적 시스템 및 프로세스(예: 우선 순위 지정 체계)를 사용하여 보고해야 합니다.

보안이 프로세스에 통합되는 방식은 팀이 학습하고 프로세스가 성숙해면서 지속적으로 개선되어야 합니다. 보안 검토 및 위험 평가는 완화가 엔드투엔드 개발 프로세스, 최종 프로덕션 서비스 및 기본 인프라에 통합되도록 해야 합니다.

DevSecOps에 대한 자세한 내용은 DevSecOps 기술 컨트롤을 참조하세요.

여정 탐색에 대한 팁

변환을 위해서는 여정에서 이상적인 상태를 점진적으로 구축해가야 합니다. 대부분의 조직은 이 여정에서 복잡성과 과제를 헤쳐나가야 합니다. 이 섹션에서는 조직이 직면하는 몇 가지 일반적인 사항에 대해 간략히 설명합니다.

• 교육과 문화의 변화는 중요한 초기 단계입니다.군대가 있어야 전쟁에 나갈 수 있습니다. 팀은 DevSecOps 모델의 다른 부분을 이해하기 위해 새로운 기술을 개발하고 새로운 관점을 채택해야 하는 경우가 많습니다. 이러한 교육 및 문화의 변화를 위해서는 개인이 변화의 가치를 완전히 이해하고 파악하도록 도울 수 있는 시간, 집중, 경영진의 후원 및 정기적인 후속 조치가 필요합니다. 문화와 기술을 획기적으로 변화시키려고 하면 개인의 직업적 정체성을 활용하여 강력한 저항이 일어나는 경우가 있습니다. 각 개인과 상황에 대한 변화의 이유, 내용, 방식을 이해하고 표현하는 것이 중요합니다.
• 변화에는 시간이 필요합니다. 새로운 방식으로 작업하는 의미에 팀이 적응할 수 있는 만큼의 속도로만 변화할 수 있습니다. 변화하는 동안에도 항상 팀은 기존 작업을 수행해야 합니다. 가장 중요한 것의 우선 순위를 신중하게 정하고 이러한 변화가 얼마나 빨리 일어날 수 있는지에 대한 기대치를 관리하는 것입니다. 가장 중요하고 기초적인 요소를 가장 앞에 두고 기어가기, 걸어가기, 달리기 전략에 중점을 두면 조직에 도움이 됩니다.
• 제한된 리소스: 조직이 일반적으로 초기에 직면하는 과제는 보안 및 애플리케이션 개발 모두에서 인재와 기술을 찾는 것입니다. 조직이 보다 효과적으로 협업하기 시작하면서 보안 사고방식을 가진 개발자나 개발 배경이 있는 보안 전문가와 같은 숨겨진 인재를 찾을 수 있습니다.
• 애플리케이션, 코드 및 인프라의 특성 변화: 애플리케이션의 기술적 정의와 구성은 서버리스, 클라우드 서비스, 클라우드 API, 코드리스 애플리케이션(예: Power Apps) 등과 같은 기술이 도입되면서 근본적으로 변화하고 있습니다. 이러한 변화는 개발 업무, 애플리케이션 보안을 변화시키고 개발자가 아니더라도 애플리케이션을 만들 수 있도록 합니다.

참고

일부 구현에서는 운영 및 보안 책임을 SRE(Site Reliability Engineer) 역할로 결합합니다.

이러한 책임을 하나의 역할로 융합하는 것이 일부 조직에는 이상적인 최종 상태일 수 있지만 현재의 기업 업무, 문화, 도구 및 기술 집합에서는 극단적인 변화인 경우가 많습니다.

SRE 모델을 목표로 하는 경우에도 투자 수익률(ROI)을 높이고 즉각적인 요구 사항을 충족할 수 있도록 이 지침에 설명된 실질적인 빠른 성과와 점진적인 진행을 사용하여 DevOps에 보안을 포함하는 것부터 시작하는 것이 좋습니다. 이렇게 하면 운영 및 개발 담당자에게 보안 책임이 점진적으로 추가되므로 직원이 SRE의 최종 상태에 더 가까워질 수 있습니다(조직에서 나중에 해당 모델을 채택할 계획인 경우).

다음 단계

DevSecOps에 대한 자세한 지침은 DevSecOps 기술 컨트롤을 검토하세요.

GitHub 고급 보안이 CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인에 보안을 통합하는 방법에 대한 자세한 내용은 GitHub 고급 보안 정보를 참조하세요.

Microsoft IT 조직에서 DevSecOps를 구현하는 방법에 대한 자세한 내용 및 도구는 보안 DevOps 도구 키트를 참조하세요.