본문으로 건너뛰기

버그 제보

이상한 점을 알려 주시면 고칠게요. 지금 보고 있는 페이지와 브라우저 정보가 함께 담겨요.

페이지:

DevOps

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

작성 2026. 10. 21.추가
목차8개 항목
출처와 참고

ByteByteGo의 System Design 101 가이드 「What is DevSecOps?」, 「Top 4 Forms of Authentication Mechanisms」를 바탕으로 재구성한 노트다. 클라우드의 보안 위협과 대응, 보안 솔루션 배치는 고려사이버대학교 「클라우드 컴퓨팅」(2023-2학기) 강의 내용으로 보강했다.

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/>사고 대응"]
개념하는 일예
위협 모델링설계 단계에서 "누가 무엇을 어떻게 노릴까"를 따져 방어를 정한다STRIDE로 데이터 흐름도 점검
자동 보안 검사정적 분석(SAST)으로 코드의 취약 패턴을, 동적 분석(DAST)으로 실행 중인 앱을 검사한다PR마다 SAST, 스테이징에서 DAST
의존성 분석(SCA)오픈소스 의존성의 알려진 취약점과 라이선스를 찾는다Dependabot, npm audit, SBOM 생성
CI/CD 자동화위 검사를 파이프라인 단계로 넣고, 기준을 넘으면 빌드를 막는다 → CI/CD심각도 높음 이상이면 머지 차단
코드형 인프라(IaC)인프라 정의도 코드로 리뷰·검사한다공개 버킷, 0.0.0.0/0 보안 그룹 탐지
컨테이너 보안최소 베이스 이미지, 루트 아닌 사용자, 이미지 취약점 스캔과 서명Dockerfile 작성과 컨테이너의 PID 1
비밀 관리비밀을 코드 밖에서 주입하고 짧게 발급한다 (아래)Vault, 클라우드 시크릿 매니저
지속 모니터링운영 중 이상 징후와 새로 공개된 취약점을 감시한다로그·감사 추적, 런타임 탐지
취약점 관리발견 → 우선순위 → 수정 → 확인의 흐름을 기한과 함께 돌린다심각도별 수정 기한
QA 연동보안 테스트 케이스를 일반 테스트와 함께 돌린다인가 우회 회귀 테스트
협업보안을 별도 팀의 일이 아니라 모든 팀의 책임으로 둔다팀마다 보안 챔피언

기계가 쓰는 자격 증명

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

형태쓰임주의
SSH 키서버·Git 원격 접속 → SSH의 동작사람·용도별로 따로, 퇴사 시 회수
OAuth 토큰·API 키서드파티 API, 서비스 간 호출 → OAuth 2.0최소 scope, 짧은 수명
TLS 인증서서버 신원 증명, 서비스 간 상호 TLS(mTLS) → HTTPS와 TLS만료 전 자동 갱신
자격 증명(아이디·비밀번호, DB 접속 정보)DB·내부 시스템 접속공유 계정 금지, 정기 교체

비밀 관리 원칙

  • 비밀은 Git 저장소에 넣지 않는다. 비공개 저장소도 마찬가지다. 한 번 커밋되면 히스토리에 남고, 저장소가 복제·공개되는 순간 퍼진다.
  • 커밋 전 훅과 CI에서 비밀 스캔을 돌리고, 유출되면 히스토리 삭제보다 키 폐기·교체가 먼저다.
  • 비밀은 비밀 관리 도구에 두고 실행 시점에 환경 변수나 파일로 주입한다 → NestJS 설정과 환경 변수
  • 가능하면 오래 사는 키 대신 짧게 발급되는 자격 증명을 쓴다. 예: CI가 클라우드에 접근할 때 저장된 액세스 키 대신 OIDC 연동으로 실행마다 임시 자격 증명을 받는다.
  • 누가 언제 어떤 비밀을 읽었는지 감사 로그를 남긴다.

클라우드의 보안 위협

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

관리적 위협내용대응
클라우드 남용누구나 큰 계산 자원을 쉽게 빌리므로 공격자도 비밀번호 크래킹·채굴·공격 기지로 쓴다. 같은 호스트 VM끼리의 트래픽은 기존 네트워크 장비가 못 보는 경우가 많다가입 시 신원 검증, 이용 행태 모니터링
악의적인 내부자퇴사자 계정이 남아 있거나 부서를 옮긴 뒤 옛 권한이 살아 있는 것이 전형. 협력사 사용자도 있다계정·권한의 지속적인 검토와 감사, 권한 분산
불투명성클라우드의 잠재 위협이 다 알려지지 않았고 사업자 내부가 보이지 않는다로그·인프라 정보 공개 요구, 모니터링 보완
이해 부족서버 기반에서 가상화 기반으로 옮기며 생긴 구조 차이를 모른 채 같은 방식으로 운영교육, 표준 아키텍처
부실한 식별·권한 관리쓰는 SaaS가 많아져 담당자도 일부만 안다(섀도 IT). 외부로 공유된 문서 속 기밀이 사각지대에 남는다(섀도 데이터)통합 인증(SSO), 최소 권한, SaaS 목록 관리
APT(지능형 지속 위협)오래 잠복하며 여러 기법을 섞는 표적 공격. 원격 접속과 데이터 집중으로 침투 경로가 많다기술적 탐지와 관리적 대응을 함께
기술적 위협내용대응
안전하지 않은 API모든 것을 API로 조작하므로, 인증 우회나 권한 밖 데이터 접근을 허용하는 API 취약점은 곧 유출과 장악이다안전한 API 설계, 앞단 웹 방화벽(API 보안)
가상화 취약점하이퍼바이저·가상 네트워크의 결함이 그 위 모든 VM으로 번진다. 가상 스위치에서 이웃 VM 패킷 엿보기(ARP 스푸핑), 게스트에서 호스트로 탈출해 다른 VM 장악하이퍼바이저 패치, 테넌트 격리, 가상 네트워크 모니터링
계정·트래픽 탈취털린 계정으로 기밀을 보고, 관리자 계정이면 다른 계정과 계약까지 바꾼다. XSS 같은 웹 취약점이 통로가 된다입출력 검증, 보안 라이브러리, 2단계 인증
데이터 유출접근 경로가 넓고, 다들 비슷하게 쓰므로 한 회사에 통한 공격이 다른 회사에도 통한다. 주로 읽기에서 생긴다암호화, 접근 통제
데이터 손실동시 편집 같은 편리함의 반대편. 악의든 실수든 지우거나 덮어쓰면 사라진다. 주로 쓰기에서 생긴다수정·삭제 권한 관리, 버전 관리와 백업
서비스 거부(DoS)자원을 소진시켜 가용성을 무너뜨린다. 자동 확장이 켜져 있으면 비용 폭탄이 된다DDoS 방어 서비스, 확장 상한과 비용 알림

취약점: CVE와 CCE

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

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

CVE 점검CCE 점검
대상소프트웨어 자체의 알려진 결함(OpenStack, Xen·KVM·QEMU 같은 플랫폼 포함)설정 미흡(약한 비밀번호 정책, 과한 파일 권한, 필요 없는 서비스)
누가 만들고 고치나벤더가 만들고 벤더가 패치사용자가 만들고 사용자가 고친다
관점알려진 취약 버전이 돌고 있나내부 정책과 규제를 지키나

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

보안 솔루션 배치

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

방식구조주의
네트워크 기반구간마다 가상 보안 어플라이언스를 두고 트래픽을 통과시킨다대량 트래픽에 여러 대가 필요하고 영역마다 따로 둔다. 자동 확장·HA가 안 되는 제품이 많다
호스트 기반서버마다 에이전트를 설치한다서버와 함께 늘어나 확장성이 중요하면 이쪽이 맞다. OS 호환성은 확인한다
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 네트워크 구성에 있다.

정리

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

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

원본 기록2

댓글

GitHub 계정으로 댓글을 남길 수 있어요.