SecOps 개념 | Notion

Security 와 Operations 가 합쳐진 개념으로, 조직의 인프라 운영에 보안을 통합하는 것을 기반으로 함
보안팀과 운영팀이 협력과 소통 문화를 조성하여 시스템을 지속 감시하고, 위협을 탐지하며, 침해사고에 대응하는 체계
효율적인 보안환경을 구축하는게 중요 → Automation, Security Orchestration
SecOps Workflow(AWS 기준)

<aside>

</aside>

📝 SecOps 로그 소스(AWS)

🔴 CloudTrail

로그 개요
- AWS 콘솔, CLI, SDK, 다른 AWS 서비스를 통해 이루어진 API 활동과, 일부 비 API 활동의 이력을 이벤트로 기록
- 확인 가능한 행위
  - 누가 작업을 수행했는가
  - 언제 작업이 발생했는가
  - 어느 IP 주소와 리전에서 요청했는가
  - 어떤 AWS 서비스와 API를 호출했는가
  - 어떤 리소스를 대상으로 작업했는가
  - 요청이 성공했는가 또는 실패했는가

이벤트에 기록되는 정보(핵심 필드)

기본 출력 형식은 JSON

"eventTime": "2026-08-05T15:30:12Z", // 이벤트 발생 시간 (UTC)
"eventSource": "iam.amazonaws.com",  // 호출된 AWS 서비스(IAM, EC2, S3)
"eventName": "CreateAccessKey",  // 실행된 API
"awsRegion": "ap-northeast-2",  // 요청이 처리된 Region
"sourceIPAddress":"58.235.187.29", // 요청 출발지 IP
"userAgent": "aws-cli/2.36.15", // 요청에 사용된 도구(콘솔, CLI, SDK)
"userIdentity": { // 작업을 수행한 주체
	"type": "IAMUser",
	"userName": "developer",
	"accessKeyId": "EXAMPLE" // 작업에 사용된 액세스 키
},
"requestParameters": {  // API 요청 내용
	"userName": "backup-svc" // 키를 발급받는 IAM 사용자
},
"responseElements": {
	"accessKey": { "accessKeyId": "NEWKEY" } // 새로 생성된 키
},
"readOnly": false, // 쓰기 작업 여부
"eventCategory": "Management", // 이벤트 유형
"eventID": "eae87c48-d421-4626-94f5-..." // 이벤트 고유 ID, SIEM에서 이벤트 중복 제거・고유 식별 키로 활용

=> developer 이 backup-svc IAM 사용자에게 액세스 키를 발급

4가지의 이벤트 유형을 기록
- Management Event - 로그인・권한변경・자원 생성・변경・삭제 행위 기록(기본 활성화)
- Data Event - 중요 S3 버킷 데이터의 경우 별도 기능 활성화 필요(비용 발생)
- Network Activity Event - VPC Endpoint로 접근한 AWS API 분석 필요 시 활성화(비용 발생)
- Insights Event - 기존 활동 대비 이상 활동 분석 필요 시 활성화(비용 발생)

CloudTrail 이벤트 이해 - AWS CloudTrail

로그 수집・저장 방법
- Event History - CloudTrail이 기본적으로 제공하는 서비스로, 관리 이벤트만 조회 가능(최근 90일, 리전 단위)
- S3 저장 - 로그를 장기 보존할 수 있고, 침해사고 발생 시 포렌식에 활용
  - 추적 생성을 통해 지정한 S3 버킷으로 로그를 지속적으로 전달
- CloudWatch - 로그 검색, Metric 필터, 알람 기능 제공
  - 추적 생성 후, CloudWatch Logs 로그 그룹과 IAM Role 을 연결하여 연동
  - https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html?utm_source=chatgpt.com
- CloudTrail Lake - SQL 기반으로 직접 조회 및 포렌식 가능
- SIEM 연동 - 일반적인 SecOps 환경에서 활용
<aside> 👉

일반적으로 S3와 CloudWatch 를 함께 사용(역할 구분)
- S3 - 원본 로그 보존, 감사・포렌식・재수집
- CloudWatch - Log Insights・경보・SIEM 전달 </aside>
탐지 가능한 위협 - “eventName” 필드만 작성 - 탐지룰 작성 시에는 “eventSource” 매핑도 필요
- 계정 및 자격증명 탈취
- 권한 상승
- 지속성 확보
- 보안 그룹 위험 설정
- 감사 및 보안 서비스 무력화
- 비인가 리전 사용
- 리소스 파괴 및 서비스 영향
- S3 데이터 접근 및 유출
- 권한 탐색 및 API 스캔
CloudTrail 한계
- AWS 계정 활동과 API 호출을 기록하지만, 리소스 내부의 행위나 네트워크 패킷은 기록 못함
  - VPC Flow Logs, WAF Logs, DNS Query Log 와 연계 필요
    
    → CloudWatch, SIEM 에서 상관분석
- 이벤트 발생 순서가 보장되지 않고, 중복 레코드가 포함될 수 있음
  - “eventTime” 을 기준으로 정렬 필요
  - “eventID” 를 문서 식별자로 사용해 중복 제거
- 로그가 비동기적으로 전달되어 지연 발생(일반 이벤트는 평균 약 5분 후 전달)
  - 탐지룰 구성 시, 지연 평가 적용
- 기본 활성 범위가 Management Event 로 제한
  - Data Event, Network Activity Event는 별도 활성화 필요 → 비용 발생
- CloudTrail 이 방어회피(StopLogging 등)에 의해 무력화 될 수 있음
  - 해당 Trail 목적지에 로그 공백 발생
  - 사전 차단 : SCP 로 관련 거부
  - 피해 최소화 : 중단 전 별도 사본 확보

🟠 VPC Flow Logs

로그 개요
- VPC 내 네트워크 인터페이스를 오가는 IP 트래픽의 메타데이터 기록(Payload는 못 봄)
- Flow Logs 활성화 단위
  
  단위 수집 범위
  
  VPC VPC 내 모든 ENI
  
  Subnet 해당 서브넷의 모든 ENI
  
  ENI 특정 인터페이스 하나
- 확인 가능한 행위
  - 어떤 출발지 IP 가 어떤 목적지 IP 와 통신했는가
  - 어떤 포트와 프로토콜을 사용했는가
  - 트래픽이 허용 되었는가, 거부 되었는가
  - 어느 네트워크 인터페이스에서 통신이 발생하는가
  - 어느 방향으로 트래픽이 이동했는가
  - 일정 시간 동안 몇 개의 패킷과 바이트가 전송되었는가

단위	수집 범위
VPC	VPC 내 모든 ENI
Subnet	해당 서브넷의 모든 ENI
ENI	특정 인터페이스 하나

이벤트에 기록되는 정보(핵심 필드)

기본 출력 형식은 텍스트(공백을 구분자로)

// 실제로는 줄바꿈 없이 한 줄로 되어 있음
------ 필드 -----
{version} {account-id} {interface-id}
{srcaddr} {dstaddr}
{srcport} {dstport} {protocol} {packets} {bytes}
{start} {end}
{action} {log-status}

------ 실제 예시 로그 ------
2 123456789012 eni-0abc123
192.168.35.215 10.0.1.55
51515 22 6 10 1020
1722873600 1722873660
ACCEPT OK

필드 설명(예시 로그 기준)

| --- | --- | --- |
분석 목적에 따라 커스텀 필드 추가 가능 → 보안 관점에서 도움되는 필드

로그 수집・저장 방법
탐지 가능한 위협
VPC Flow Logs 한계