DevSecOps와 클라우드 보안: 개발 흐름에 보안 넣기, 위협과 대응

DevSecOps란

DevSecOps는 개발(Dev)·보안(Sec)·운영(Ops)을 한 흐름으로 묶어, 보안을 소프트웨어 수명 주기 전 단계에 넣는 방식이다. DevOps가 개발과 운영 사이의 벽을 허문 것처럼, 보안팀이 출시 직전에 한 번 검사하던 관문을 없애고 검사를 파이프라인 곳곳에 자동으로 심는다.

문제는 늦게 발견할수록 고치는 비용이 커진다는 것이다. 그래서 검사를 왼쪽(앞 단계)으로 당기는 시프트 레프트(shift left) 가 핵심 원칙이다.

단계별로 넣는 것

flowchart LR
  a["설계"] --> b["코드"] --> c["빌드"] --> d["테스트"] --> e["배포"] --> f["운영"]
  a -.- a1["위협 모델링"]
  b -.- b1["시크릿 스캔<br/>리뷰"]
  c -.- c1["SCA<br/>SAST<br/>이미지 스캔"]
  d -.- d1["DAST<br/>QA 연동"]
  e -.- e1["IaC 검사<br/>서명 검증"]
  f -.- f1["모니터링<br/>취약점 관리<br/>사고 대응"]

기계가 쓰는 자격 증명

사람의 로그인 말고도 시스템끼리는 여러 형태의 비밀로 서로를 확인한다.

비밀 관리 원칙

• 비밀은 Git 저장소에 넣지 않는다. 비공개 저장소도 마찬가지다. 한 번 커밋되면 히스토리에 남고, 저장소가 복제·공개되는 순간 퍼진다.
• 커밋 전 훅과 CI에서 비밀 스캔을 돌리고, 유출되면 히스토리 삭제보다 키 폐기·교체가 먼저다.
• 비밀은 비밀 관리 도구에 두고 실행 시점에 환경 변수나 파일로 주입한다 → NestJS 설정과 환경 변수
• 가능하면 오래 사는 키 대신 짧게 발급되는 자격 증명을 쓴다. 예: CI가 클라우드에 접근할 때 저장된 액세스 키 대신 OIDC 연동으로 실행마다 임시 자격 증명을 받는다.
• 누가 언제 어떤 비밀을 읽었는지 감사 로그를 남긴다.
• 사람끼리 비밀을 건넬 때도 도구를 쓴다. API 키를 메신저 DM이나 메일로 보내면 대화 기록에 평문으로 남는다. 1Password 같은 팀용 비밀번호 관리자의 공유 금고를 쓰고, 직접 운영해야 하면 Bitwarden 호환 서버를 셀프 호스팅한다.

침해를 전제로 설계한다

AI를 이용한 자동화 공격이 늘면서 규모와 상관없이 대부분의 조직이 공격 대상이 된다. 완벽한 방어를 목표로 하기보다 「털려도 피해가 어디까지인가」를 설계 질문으로 둔다.

클라우드의 보안 위협

클라우드 보안은 공동 책임이다. 사업자가 물리 시설·하드웨어·가상화 계층을 맡고, 그 위는 서비스 모델에 따라 사용자 몫이다(서비스 모델). 여러 고객이 큰 인프라와 중앙의 데이터를 나눠 쓰는 멀티테넌트 환경이라, 위협은 사람·절차 쪽(관리적)과 시스템 쪽(기술적)으로 나눠 본다.

취약점: CVE와 CCE

알려지지 않은 취약점 공격은 시점에 따라 부른다. 제로데이는 아직 공개·패치되지 않은 취약점이라 드물지만 막기 어렵고, 원데이는 공개 직후 패치가 퍼지기 전을 노리고, 올드데이는 패치가 나온 지 한참 됐는데 적용하지 않은 시스템을 노린다. 가장 흔한 것은 비용이 싼 올드데이라서, 패치를 제때 하는 것만으로 상당수를 막는다.

시스템 취약점은 두 갈래로 점검한다.

병목은 패치가 아니라 운영이다

AI가 취약점을 찾고 악용하는 비용을 낮추면서, 공격자와 방어자가 같은 속도로 결함을 찾아 공개 건수가 한꺼번에 몰린다. 메인테이너 쪽에서는 하위 호환을 깨지 않는 수정안을 찾기 어렵고, 재현되지 않거나 중복된 제보를 걸러 내는 일도 쌓인다. 운영 쪽의 부담은 패치를 쓰는 일보다 영향받는 구성 요소가 어디에 숨어 있는지 찾고(라이브러리 안, 프로그램별 인증서 저장소까지), 우리 환경이 실제로 노출되는지 판단하고, 업데이트를 테스트하는 일에 있다. 이 일은 시스템을 가장 잘 아는 소수에게 몰려 번아웃으로 이어진다.

커널 패치의 병목은 배포가 아니라 다운타임이다. 전체 서버에 패키지 업데이트와 재부팅 명령을 내리는 일은 Ansible 같은 구성 관리 도구로 금방 끝난다. 어려운 것은 커널 교체에 따르는 재부팅과 그동안의 서비스 중단을 서비스 담당 조직과 조율하는 일이다. 중단을 이유로 패치를 미루면 그 기간만큼 알려진 취약점을 안고 운영하게 되므로(위의 올드데이), 취약점이 나올 때마다 일정을 협상하지 말고 정기 점검 창구를 미리 확보해 둔다. RHEL 같은 유료 배포판은 패치 지원을 계약으로 보장받는다는 장점이 있지만, 새 취약점이 계속 나오고 그때마다 재부팅 일정을 잡아야 하는 사정은 같다.

노출 여부는 공격을 재현하지 않고 판단한다. 웹 서버 취약점(예: HTTP/2 처리 모듈의 레이스 컨디션으로 인한 원격 코드 실행)이 공개됐을 때, 공격 코드를 돌려 보지 않아도 아래 항목으로 영향 여부를 가릴 수 있다.

실제 공격 코드로 검증해야 한다면 본인 소유이거나 명시적으로 허가받은, 운영과 분리된 테스트 환경에서만 한다.

규모가 크고 정책이 복잡한 클라우드는 CCE 쪽에 특히 약하다. 공개된 버킷, 0.0.0.0/0으로 열린 보안 그룹, 꺼진 로깅 같은 설정 오류를 계속 검사하는 도구(CSPM, Cloud Security Posture Management)를 쓰는 이유이고, 같은 검사를 배포 전 IaC 단계로 당긴 것이 위 표의 「코드형 인프라」 검사다.

보안 솔루션 배치

클라우드에서 보안 솔루션은 서비스와 함께 늘어날 수 있는지를 먼저 본다. 보안 장비가 확장을 막으면 결국 교체하거나 구조를 다시 짜야 한다.

flowchart TB
  user["사용자"] -->|"HTTPS"| waf["WAF / DDoS 방어"] --> lb["로드 밸런서"]
  subgraph pub["퍼블릭 서브넷"]
    web["웹 서버들<br>(보안 그룹, 호스트 IPS)"]
  end
  subgraph priv1["프라이빗 서브넷"]
    app["앱 서버들<br>(보안 그룹)"]
  end
  subgraph priv2["프라이빗 서브넷"]
    db["DB<br>(보안 그룹: 앱 서버에서만)"]
  end
  lb --> web --> app --> db
  office["사무실"] -->|"VPN·전용선"| adm["관리 접근<br>(접근 제어, 디렉터리 인증)"]
  layers["모든 계층"] -->|"로그"| mon["모니터링·탐지"]

온프레미스가 경계 방화벽 장비로 막았다면, 클라우드는 보안 그룹처럼 API로 설정하는 자원 단위 접근 제어가 기본이라 더 세밀하고 코드로 관리된다. 망 구성은 AWS VPC 네트워크 구성에 있다.

공급망 공격: 배포 파일이 변조될 때

소프트웨어 공급망 공격(supply chain attack) 은 목표 시스템을 직접 뚫지 않고, 그 시스템이 믿고 받아 쓰는 코드·파일을 변조한다. 사용자가 공식 앱을 정상적으로 실행하기만 해도 감염된다. 의존성 패키지(npm 설치 스크립트 → npm install이 하는 일), 남의 도메인에서 불러오는 스크립트(polyfill.io 사례 → ECMAScript 표준과 TC39 프로세스), 배포 CDN의 파일이 모두 통로가 된다.

2026년 11월 공개된 한 PC 게임 런처 사고가 전형적인 모양이다. 퍼블리셔 CDN에 올라간 공식 JavaScript 파일 네 개에 짧은 로더가 끼워졌고, 런처의 내장 브라우저가 이 파일을 불러 외부 서버에서 원격 제어 에이전트를 받아 실행했다. 에이전트는 임의 명령 실행, 저장된 로그인·브라우저 비밀번호·쿠키 수집, SSH 키·개발자 토큰 읽기, 암호화폐 지갑 확장 데이터 수집까지 했다. 런처가 관리자 권한을 요구하는 탓에 에이전트도 높은 권한으로 돌았다. Linux의 Proton(Wine) 환경도 안전하지 않았다. Wine이 Linux 홈 폴더를 그대로 보여 주기 때문이다.

막는 쪽: 배포하는 입장

당한 쪽: 감염이 의심되는 PC

1. 증거부터 남긴다. 앱을 다시 실행하거나 재설치하기 전에 로그·캐시 폴더를 확인하거나 복사한다. 재설치하면 흔적이 지워져 감염 여부를 알 수 없다. 흔적이 없다는 것이 안전하다는 뜻은 아니다.
2. 격리한다. 의심되는 앱을 닫고 그 PC의 네트워크를 끊는다. 공개된 악성 도메인·IP는 hosts 파일·공유기·방화벽에서 막는다.
3. 깨끗한 다른 기기에서 계정을 정리한다. 감염된 PC에서 바꾼 비밀번호는 다시 새어 나갈 수 있다. 주요 계정(이메일, 금융, 브라우저에 저장된 사이트) 비밀번호를 바꾸고, 2단계 인증을 켜고, 로그인된 세션을 모두 끊는다. 세션 쿠키가 털렸다면 비밀번호만 바꿔서는 막히지 않는다.
4. 기계용 비밀을 교체한다. API 토큰, SSH 키, 개발 도구 자격 증명을 폐기하고 새로 발급한다(위 「기계가 쓰는 자격 증명」). 지갑은 새 시드로 옮긴다.
5. 시스템을 복구한다. 지속성(자동 실행 등록, 레지스트리 키, 심어진 DLL)을 지우거나, 가장 확실하게는 OS를 다시 설치한다. 백신이 놓치는 경우도 있다.

정리

• DevSecOps는 보안 검사를 마지막 관문에서 파이프라인 전체로 옮기고 자동화한다.
• 설계는 위협 모델링, 코드는 SAST·시크릿 스캔, 빌드는 SCA·이미지 스캔, 배포는 IaC 검사, 운영은 모니터링과 취약점 관리가 맡는다.
• 기계용 자격 증명(SSH 키, 토큰, 인증서, 접속 정보)은 저장소 밖에서 주입하고, 짧게 발급하고, 유출되면 즉시 교체한다.
• 공급망 공격은 믿고 받는 파일을 변조한다. 배포하는 쪽은 무결성 검증과 배포 경로 최소 권한으로 막고, 당한 쪽은 증거 보존 → 격리 → 깨끗한 기기에서 비밀번호·세션·토큰 교체 순서로 대응한다.
• 클라우드 사고 대부분은 설정 오류와 권한 관리 실수에서 나온다. 관리적 위협과 기술적 위협을 나눠 대응하고, 패치(CVE)와 설정 점검(CCE)을 계속 돌리고, 보안 솔루션은 확장성을 먼저 본다.

관련 노트: CI/CD, 보안 시스템 설계: 원칙과 민감 데이터 관리, API 보안 체크리스트, Dockerfile 작성과 컨테이너의 PID 1, SSH의 동작: 전송·인증·연결 계층, 클라우드 기초와 AWS, 쿠버네티스 보안, AWS VPC 네트워크 구성