DevOps의 보안(DevSecOps)

  • 아티클

보안은 DevOps의 핵심 부분입니다. 그러나 팀이 시스템이 안전한지 어떻게 알 수 있을까요? 완전히 안전한 서비스를 제공할 수 있나요?

불행하게도, 대답은 아니오입니다. DevSecOps는 개발 및 IT 운영 모두에서 모든 사용자의 관심을 필요로 하는 지속적이고 지속적인 노력입니다. 작업이 실제로 수행되지는 않지만 팀이 위반을 방지하고 처리하기 위해 사용하는 관행은 가능한 한 안전하고 탄력적인 시스템을 생성하는 데 도움이 될 수 있습니다.

"근본적으로, 누군가가 들어오고 싶다면, 그들은 들어오고 있습니다... 수락합니다. 우리가 고객에게 말하는 것은 : 번호 1, 당신은 당신이 생각 여부, 싸움에있어. 둘째, 당신은 거의 확실하게 침투합니다." - 마이클 헤이든, 전 NSA 국장 및 CIA

보안 대화

공식적인 DevSecOps 전략이 없는 팀은 가능한 한 빨리 계획을 시작하는 것이 좋습니다. 처음에는 존재하는 위협을 충분히 인식하지 못하는 팀원의 저항이 있을 수 있습니다. 다른 사람들은 팀이 문제에 직면할 준비가 되어 있으며 특별한 투자가 기능을 전달하는 데 쓸데없이 방해가 된다고 느끼지 않을 수 있습니다. 그러나 위험의 특성, 팀이 위험을 완화할 수 있는 방법 및 팀에 현재 가지고 있지 않은 리소스가 필요한지 여부에 대한 합의를 도출하기 위해 대화를 시작해야 합니다.

회의론자들이 다음과 같은 몇 가지 일반적인 논쟁을 일으킬 것으로 예상합니다.

  • 위협은 얼마나 실제적인가요? 팀은 보호해야 하는 서비스와 데이터의 잠재적 가치를 인식하지 못하는 경우가 많습니다.
  • 팀이 잘하고 있습니다. 그렇죠? 보안 논의는 보안 시스템을 구축하는 팀의 능력에 의문이 있는 것으로 인식될 수 있습니다.
  • 가능하다고 생각하지 않습니다. 이는 주니어 엔지니어의 일반적인 논쟁입니다. 경험이 있는 사람은 일반적으로 더 잘 알고 있습니다.
  • 합의를 위반한 적이 없습니다. 하지만 어떻게 알고 있나요? 어떻게 알게 되나요?
  • 가치에 대한 끝없는 논쟁입니다. DevSecOps는 핵심 기능 작업에 방해가 되는 것으로 인식될 수 있는 심각한 약정입니다. 보안 투자는 다른 요구 사항과 균형을 유지해야 하지만 무시할 수는 없습니다.

사고방식 변화

DevSecOps 문화권에는 사고방식의 중요한 변화가 필요합니다. 위반을 방지할 뿐만 아니라 위반을 가정해야 합니다.

보안 전략 구성 요소

더 안전한 시스템에 대한 탐구에 적용할 수 있는 많은 기술이 있습니다.

위반 방지 위반 가정
위협 모델 전쟁 게임 연습
코드 검토 중앙 보안 모니터
보안 테스트 라이브 사이트 침투 테스트
SDL(보안 개발 수명 주기)

모든 팀에는 이미 위반 방지를 위한 몇 가지 관행이 있어야 합니다. 보안 코드 작성은 거의 기본값이 되었으며 정적 분석 및 기타 보안 테스트 기능을 지원하는 무료 및 상용 도구가 많이 있습니다.

그러나 많은 팀에서 시스템 위반이 불가피하다고 가정하는 전략이 부족합니다. 위반되었다고 가정하면 특히 경영진과 어려운 대화를 나눌 때 인정하기 어려울 수 있지만, 이러한 가정은 자신의 시간에 보안에 대한 질문에 대답하는 데 도움이 될 수 있습니다. 당신은 실제 보안 비상 사태 동안 모든 것을 파악하고 싶지 않아요.

고려해야 할 일반적인 질문은 다음과 같습니다.

  • 공격을 감지하려면 어떻게 해야 할까요?
  • 공격이나 침투가 있는 경우 어떻게 대응하나요?
  • 데이터가 유출되거나 변조된 경우와 같은 공격으로부터 어떻게 복구할 수 있나요?

주요 DevSecOps 사례

거의 모든 팀에 적용되는 몇 가지 일반적인 DevSecOps 사례가 있습니다.

먼저 평균 검색 시간 및 평균 복구 시간을 개선하는 데 집중합니다. 이러한 메트릭은 위반을 감지하는 데 걸리는 시간과 각각 복구하는 데 걸리는 시간을 나타냅니다. 보안 응답 계획의 지속적인 라이브 사이트 테스트를 통해 추적할 수 있습니다. 잠재적인 정책을 평가할 때 이러한 메트릭을 개선하는 것은 중요한 고려 사항입니다.

심층 방어 연습. 위반이 발생하면 공격자는 내부 네트워크와 내부 모든 네트워크에 액세스할 수 있습니다. 공격자를 중지하는 것이 이상적이지만, 위반을 가정하는 정책은 팀이 이미 들어온 공격자의 노출을 최소화하도록 유도합니다.

마지막으로, 사례 및 환경에 대한 주기적인 위반 후 평가를 수행합니다. 위반이 해결된 후 팀은 정책의 성능과 정책 준수를 평가해야 합니다. 정책은 팀이 실제로 정책을 따를 때 가장 효과적입니다. 실제 위반이든 연습이든 모든 위반은 개선할 수 있는 기회로 여겨져야 합니다.

위협 완화 전략

모든 위협을 열거하기에는 너무 많은 위협이 있습니다. 일부 보안 허점은 운영 체제 및 라이브러리와 같은 종속성 문제로 인해 발생하므로 최신 상태로 유지하는 것이 중요합니다. 다른 오류는 찾아서 수정하기 위해 신중한 분석이 필요한 시스템 코드의 버그 때문입니다. 열악한 비밀 관리는 소셜 엔지니어링과 마찬가지로 많은 보안 위반의 원인입니다. 다양한 종류의 보안 구멍과 시스템에 대한 의미를 생각하는 것이 좋습니다.

공격 벡터

공격자가 개발자의 자격 증명에 액세스할 수 있는 시나리오를 고려합니다. 그들은 무엇을 할 수 있는가?

Privilege 공격
이메일을 보낼 수 있나요? 동료 피싱
다른 머신에 액세스할 수 있나요? 로그온, mimikatz, 반복
원본을 수정할 수 있나요? 코드 삽입
빌드/릴리스 프로세스를 수정할 수 있나요? 코드 삽입, 스크립트 실행
테스트 환경에 액세스할 수 있나요? 프로덕션 환경에서 테스트 환경에 대한 종속성을 사용하는 경우 이를 악용합니다.
프로덕션 환경에 액세스할 수 있나요? 많은 옵션...

팀이 이러한 벡터에 대해 어떻게 방어할 수 있나요?

  • 보호된 자격 증명 모음에서 비밀 저장
  • 로컬 관리자 계정 제거
  • SAMR 제한
  • Credential Guard
  • 이중 홈 서버 제거
  • 별도의 구독
  • Multi-Factor Authentication
  • 권한 있는 액세스 워크스테이션
  • ATP를 사용하여 검색 및 클라우드용 Microsoft Defender

비밀 관리

모든 비밀은 보호된 자격 증명 모음에 저장되어야 합니다. 비밀은 다음과 같습니다.

  • 암호, 키 및 토큰
  • Storage 계정 키
  • 인증서
  • 공유된 비프로덕션 환경에서도 사용되는 자격 증명

자격 증명 모음의 계층 구조를 사용하여 비밀 중복을 제거해야 합니다. 또한 비밀에 액세스하는 방법과 시기를 고려합니다. 일부는 환경 구성을 빌드할 때 배포 시 사용되는 반면 다른 일부는 런타임에 액세스됩니다. 배포 시간 비밀은 일반적으로 새 설정을 선택하기 위해 새 배포가 필요한 반면 런타임 비밀은 필요할 때 액세스되고 언제든지 업데이트할 수 있습니다.

플랫폼에는 CI/CD 파이프라인 및 클라우드 환경(예: Azure Key Vault및 GitHub Actions)에서 비밀을 관리하기 위한 보안 스토리지 기능이 있습니다.

유용한 도구

전쟁 게임 연습

Microsoft의 일반적인 사례는 전쟁 게임 연습에 참여하는 것입니다. 두 팀이 시스템의 보안 및 정책을 테스트하는 보안 테스트 이벤트입니다.

빨간색 팀은 공격자의 역할을 맡습니다. 보안의 격차를 찾기 위해 실제 공격을 모델링하려고 합니다. 악용할 수 있는 경우 위반의 잠재적 영향도 보여 줍니다.

파란색 팀은 DevOps 팀의 역할을 맡습니다. 레드 팀의 공격을 감지하고 대응하는 능력을 테스트합니다. 이를 통해 상황 인식을 향상시키고 DevSecOps 전략의 준비 상태와 효율성을 측정할 수 있습니다.

전쟁 게임 전략 진화

전쟁 게임은 레드 팀이 문제를 찾고 악용하도록 동기를 부여하기 때문에 보안을 강화하는 데 효과적입니다. 그것은 아마 초기에 예상보다 훨씬 쉬울 것입니다. 자신의 시스템을 적극적으로 공격하지 않은 팀은 일반적으로 공격자가 사용할 수 있는 보안 구멍의 크기와 양을 인식하지 못합니다. 파란색 팀은 반복적으로 실행되기 때문에 처음에는 사기를 쳐질 수 있습니다. 다행히 블루 팀이 일관되게 이길 수 있도록 시스템과 관행은 시간이 지남에 따라 진화해야 합니다.

전쟁 게임 준비

전쟁 게임을 시작하기 전에 팀은 보안 패스를 통해 찾을 수 있는 문제를 처리해야 합니다. 이 연습은 공격을 시도하기 전에 수행할 수 있는 좋은 연습입니다. 첫 번째 악용이 나중에 발견된 후 모든 사용자가 비교할 수 있는 기준 환경을 제공하기 때문입니다. 수동 코드 검토 및 정적 분석 도구를 통해 취약성을 식별하여 시작합니다.

팀 구성

빨간색과 파란색 팀은 전문 분야로 구성되어야 합니다. 목표는 가능한 한 효과적으로 실행하기 위해 각 팀에 가장 유능한 팀을 구축하는 것입니다.

레드 팀에는 코드에 대해 잘 알고 있는 보안 관련 엔지니어와 개발자가 포함되어야 합니다. 가능한 경우 침투 테스트 전문가로 팀을 보강하는 것도 유용합니다. 사내 전문가가 없는 경우 많은 회사에서 멘토링과 함께 이 서비스를 제공합니다.

블루 팀은 사용 가능한 시스템과 로깅에 대한 깊은 이해를 가진 작전 지향적 엔지니어로 구성되어야 합니다. 의심스러운 동작을 감지하고 해결할 수 있는 가장 좋은 기회가 있습니다.

초기 전쟁 게임 실행

레드 팀이 초기 전쟁 게임에서 효과적일 것으로 기대합니다. 제대로 보호되지 않는 비밀 찾기, SQL 삽입 및 성공적인 피싱 캠페인과 같이 매우 간단한 공격을 통해 성공할 수 있어야 합니다. 정책에 대한 수정 사항 및 피드백을 적용하려면 라운드 간에 충분한 시간을 할애하세요. 이는 조직에 따라 다르지만 모든 사람이 이전 라운드가 가치 있는 모든 것을 위해 채굴되었다고 확신할 때까지 다음 라운드를 시작하고 싶지 않습니다.

진행 중인 전쟁 게임

몇 라운드 후에 레드 팀은 XSS(교차 사이트 스크립팅), 역직렬화 익스플로잇 및 엔지니어링 시스템 취약성과 같은 보다 정교한 기술에 의존해야 합니다. Active Directory와 같은 영역에서 외부 보안 전문가를 데려오는 것이 더 모호한 악용을 공격하는 데 도움이 될 수 있습니다. 이 때까지 파란색 팀은 방어할 수 있는 강화된 플랫폼을 갖추어야 할 뿐만 아니라 위반 후 포렌식에 대한 포괄적인 중앙 집중식 로깅을 사용할 것입니다.

"수비수는 목록에서 생각합니다. 공격자는 그래프로 생각합니다. 이것이 사실인 한, 공격자는 승리합니다." -- 존 램버트 (MSTIC)

시간이 지남에 따라 레드 팀은 목표에 도달하는 데 훨씬 더 오래 걸릴 것입니다. 이렇게 하면 여러 취약성을 검색하고 연결하여 영향을 제한해야 하는 경우가 많습니다. 실시간 모니터링 도구를 사용하여 파란색 팀은 실시간으로 시도를 catch하기 시작해야 합니다.

지침

전쟁 게임은 모두를위한 자유가 되어서는 안됩니다. 목표는 보다 효과적인 팀이 운영하는 보다 효과적인 시스템을 생성하는 것임을 인식하는 것이 중요합니다.

사용 규정

다음은 Microsoft에서 사용하는 샘플 행동 강령입니다.

  1. 빨간색과 파란색 팀 모두 해를 끼치지 않습니다. 손상을 일으킬 가능성이 큰 경우 문서화하고 해결해야 합니다.
  2. 빨간색 팀은 대상 자산을 캡처하는 데 필요한 것보다 더 많은 것을 손상해서는 안 됩니다.
  3. 상식 규칙은 물리적 공격에 적용됩니다. 레드 팀은 소셜 엔지니어링과 같은 비기술적 공격으로 창의력을 발휘하는 것이 권장되지만 가짜 배지를 인쇄하거나 사람들을 괴롭히지 않아야 합니다.
  4. 사회 공학 공격이 성공하면 손상된 사람의 이름을 공개하지 마십시오. 이 수업은 모든 사람이 계속 작업해야 하는 팀원을 소외하거나 당황하게 하지 않고 공유할 수 있습니다.

참여 규칙

다음은 Microsoft에서 사용하는 참여의 샘플 규칙입니다.

  1. 시스템의 가용성에 영향을 주지 않습니다.
  2. 외부 고객 데이터에 액세스하지 마세요.
  3. 모든 서비스에 대한 현재 위치 보안 보호를 크게 약화시키지 마세요.
  4. 리소스에 대해 의도적으로 파괴적인 작업을 수행하지 마세요.
  5. 금고 자격 증명, 취약성 및 기타 중요한 정보를 가져옵니다.

결과물

학습된 모든 보안 위험 또는 교훈은 복구 항목의 백로그에 문서화되어야 합니다. 팀은 보안 위험을 얼마나 빨리 해결할 것인지에 대한 SLA(서비스 수준 계약)를 정의해야 합니다. 심각한 위험은 가능한 한 빨리 해결해야 하는 반면, 사소한 문제는 2 스프린트 마감일이 있을 수 있습니다.

학습된 교훈과 취약성이 발견된 보고서를 전체 조직에 제공해야 합니다. 모두에게 학습 기회이므로 최대한 활용하세요.

Microsoft에서 배운 교훈

Microsoft는 정기적으로 전쟁 게임을 연습하고 그 과정에서 많은 교훈을 배웠습니다.

  • 전쟁 게임은 DevSecOps 문화를 바꾸고 보안을 최우선으로 유지하는 효과적인 방법입니다.
  • 피싱 공격은 공격자에게 매우 효과적이며 과소 평가해서는 안됩니다. 프로덕션 액세스를 제한하고 2단계 인증을 요구하여 영향을 포함할 수 있습니다.
  • 엔지니어링 시스템을 제어하면 모든 것을 제어할 수 있습니다. 빌드/릴리스 에이전트, 큐, 풀 및 정의에 대한 액세스를 엄격하게 제어해야 합니다.
  • 공격자가 더 어렵게 만들기 위해 심층 방어를 연습합니다. 위반해야 하는 모든 경계는 속도를 늦추고 이를 잡을 수 있는 또 다른 기회를 제공합니다.
  • 신뢰 영역을 교차하지 마십시오. 프로덕션은 테스트에서 아무것도 신뢰하지 않아야 합니다.

다음 단계

Azure의 보안 개발 수명 주기 및 DevSecOps에 대해 자세히 알아봅니다.