보안 팀의 업무는 보통 규칙(rule)을 작성하는 것부터 시작됩니다. 그러나 시간이 지남에 따라 규칙의 수가 늘어나고 서로 달라지며 일관성을 잃게 되는 경우가 많습니다. 초기에는 단 몇 개의 탐지 규칙으로 시작해도 어느새 빠르게 운영상의 문제로 확대됩니다. 중복되는 로직도 있고, 이름도 일관되지 않으며, 누가 변경했는지 확인할 수 있는 가시성도 부족해집니다.
탐지 엔지니어링은 이러한 문제를 해결할 수 있습니다. 탐지 작업을 코드로 관리하면(detection-as-code) 담당팀은 소프트웨어를 배포하듯 SIEM 콘텐츠를 버전 관리하고 검토하고 테스트하고 배포할 수 있습니다.
이 가이드에서는 다음과 같은 방법을 소개합니다.
- GitHub 리포지토리에 Sumo Logic 클라우드 SIEM 규칙을 저장하는 방법
- 테라폼을 사용해 일관된 방식으로 배포하는 방법
- GitHub Actions를 사용해 검증 및 자동화를 적용하는 방법
- OIDC를 사용해 AWS S3에 테라폼 상태를 안전하게 저장하는 방법
목표: 개발·운영(DevOps)의 엄격함을 SOC에 적용하는 것입니다. 모든 탐지 작업은 버전 관리되고, 테스트 가능하며, 반복 가능한 형태가 됩니다.
코드 기반 탐지의 중요성
| 문제점 | 코드 기반 탐지를 통한 해결 방법 |
| 탐지 규칙 변동 및 불일치 | 중앙 집중식 버전 관리로 일관성 유지 |
| 수작업에 의한 배포 및 인간에 의한 오류 | 자동화된 CI/CD 파이프라인으로 예측 가능한 롤아웃 |
| 제한된 협업 | 풀 리퀘스트(Pull Request)를 통해 모든 규칙을 감사 및 검토 |
| 어려운 롤백 또는 테스트 | 버전 기록을 통해 안전한 승격 및 즉시 롤백 |
코드 기반 탐지(detection-as-code)는 SIEM을 정적인 구성에서 엔지니어링 규율에 따라 설계·테스트·배포되는 살아 있는 시스템으로 변화시킵니다.
구축할 사항
다음 기능을 갖춘 GitHub 리포지토리를 만들겠습니다.
- 클라우드 SIEM 탐지를 YAML 또는 JSON 형식의 코드로 저장하는 기능
- 테라폼을 사용해 Sumo Logic 환경에 변경 사항을 적용하는 기능
- GitHub Actions를 통해 배포를 자동화하는 기능
- 정적 자격 증명을 사용하지 않고 OIDC를 사용해 AWS S3 버킷에 테라폼 상태를 저장하는 기능
이러한 아키텍처는 수작업에서 발생하는 오류를 제거하고 반복 속도를 높이며 모든 환경에서 SOC가 전체를 감사할 수 있도록 지원합니다.
설정 단계
규칙 관리를 위한 GitHub 리포지토리는 조직의 계정으로 설정하는 것이 좋습니다. 규칙 관리 리포지토리는 다른 기능이나 제품과 공유하지 않는 것이 좋습니다.
사전 준비 사항
- 상태 관리를 위한 S3 버킷이 있는 AWS 계정
- GitHub 계정 및 리포지토리 – 새 리포지터리 만들기 – GitHub 문서
- Sumo Logic 계정
자격 증명
AWS 자격 증명 및 Sumo Logic 자격 증명은 GitHub 시크릿에 저장됩니다. 테라폼은 이러한 자격 증명을 사용해 AWS 및 Sumo Logic을 인증합니다.
Sumo API 자격 증명
Sumo Logic 자격 증명을 가져오는 방법은 다음과 같습니다.
AWS 설정
AWS 버킷 생성 및 자격 증명은 다음과 같은 단계를 따라 진행할 수 있습니다.
- AWS 콘솔에서 검색창에 S3를 입력해 S3 페이지로 이동한 뒤 버킷 생성(Create bucket)을 클릭합니다.
- 버킷 이름에는 원하는 이름을 입력하고 나머지 옵션은 기본값 그대로 둔 후 버킷을 생성합니다.
- IAM > Policies 페이지로 이동하여 정책 생성(Create Policy)을 클릭합니다.
- 정책 편집기에서 JSON 보기로 전환한 뒤 ‘Statement’ 필드에 아래의 명령문을 붙여 넣고 ‘bucket-name’을 위 2번에서 생성한 버킷 이름으로 교체한 후 다음(Next)을 클릭합니다.
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::bucket-name",
"Condition": {
"StringEquals": {
"s3:prefix": "terraform-state"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state.tflock"
}
]
- 다음 페이지에서 정책 이름을 입력하고 정책 생성(Create Policy)을 클릭합니다.
- 다음 문서의 안내에 따라 AWS에 ID 공급자(Identity Provider)를 추가합니다.https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-console
- 공급자 URL: https://token.actions.githubusercontent.com
- 대상(Audience): sts.amazonaws.com
- IAM > Roles 페이지로 이동해 역할 생성(Create Role)을 클릭합니다.
- 신뢰할 수 있는 엔터티 유형(Trusted entity type)에서는 Web Identity를 선택하고, ID 공급자(identity provider)로 token.actions.githubusercontent.com, 대상(Audience)은 sts.amazonaws.com을 선택합니다. 이 리포지토리가 포크된 GitHub 조직 이름을 입력하고 다음 단계로 이동합니다.
- 권한 추가(Add Permissions) 페이지에서 위 5번에서 생성한 정책을 선택합니다.
- 역할 이름을 입력하고 역할 생성(Create Role)을 클릭합니다.
- GitHub 리포지토리에서 Settings > Secrets and variables > Actions> Variables로 이동해
AWS_ROLE_ARN, BUCKET_NAME, BUCKET_REGION변수를 방금 생성한 역할의 ARN, 버킷 이름 및 지역으로 추가 또는 교체합니다. - GitHub 작업 시크릿
- Sumo Logic 자격 증명(Personal Access Keys)은 리포지토리 시크릿에 저장되며 테라폼 GitHub Action에서 액세스할 수 있습니다. 마찬가지로 S3 backend에 액세스할 때 사용하는 AWS 역할, 버킷 이름, 버킷 지역도 리포지토리 변수 섹션에 저장됩니다. 해당 시크릿과 변수는 Settings > Secrets and variables > Actions에서 업데이트할 수 있습니다.
SUMOLOGIC_ACCESSID
SUMOLOGIC_ACCESSKEY
AWS_ROLE_ARN
BUCKET_NAME
BUCKET_REGION
로컬 실행
로컬에서 실행할 경우 위에서 설명한 AWS 설정 방식은 작동하지 않으며 대신 AWS 액세스 자격 증명을 사용해야 합니다. 이 자격 증명은 아래 단계를 통해 생성할 수 있습니다. (이미 S3 버킷과 정책을 생성한 상태여야 합니다. 그렇지 않다면 AWS 설정의 1–5단계를 먼저 수행해야 합니다.)
- IAM > Users 페이지로 이동해 사용자 생성(Create User)을 클릭합니다.
- 사용자 이름을 입력하고 다음을 클릭합니다.
- 권한 설정(Set Permissions) 페이지에서 정책 직접 첨부(Attach Policies Directly)를 클릭한 뒤 이전에 생성한 정책을 선택합니다. 다음 페이지에서 ‘사용자 생성(Create User)’을 클릭합니다.
- IAM > Users 페이지로 돌아가 새로 생성된 사용자를 클릭합니다.
- Security Credentials 탭에서 Access Keys 섹션의 액세스 키 생성(Create Access Key)을 클릭합니다.
- Use case는 CLI를 선택하고 체크박스를 선택한 뒤 다음을 클릭합니다.
- 필요한 경우 태그를 설정하고 다음을 클릭합니다. 이 단계에서 AWS 액세스 키와 시크릿 액세스 키가 생성됩니다. 이를 각각
AWS_ACCESS_KEY_ID및AWS_SECRET_ACCESS_KEY라는 환경 변수로 내보냅니다.
탐지 테스트 및 승격
수행 규칙 승격을 관리하려면 브랜치 및 환경 격리를 사용해야 합니다
- 기능 브랜치 → 개발 및 유효성 검증
- 풀 리퀘스트 → 동료 검토 및 계획 승인
- 메인 브랜치 → 개발(dev) 환경으로 자동 배포
- 매뉴얼 워크플로 트리거 → 테스트 또는 운영 환경으로 승격
품질 유지를 위해 YAML 린팅, 정책 테스트, 메타데이터 검증 등을 추가합니다.
이러한 개발·보안·운영(DevSecOps) 방식의 워크플로는 오탐(false positives)을 줄이고 반복 속도를 높이며 탐지 결과의 신뢰도를 높입니다.
운영 규율
성숙한 탐지 프로그램은 운영상의 일관성에 기반합니다.
다음과 같은 규칙을 도입합니다.
소유자, 사용 사례,런북 URL과 같은 메타데이터 필드를 포함할 것.- 일시적으로 비활성화된 규칙에는
enabled: false를 사용할 것. - 이름 규칙과 유지 관리 기간을 준수할 것.
테라폼 플랜을 이용해 매일 야간 변동 사항 점검을 실시할 것.
강력한 프로세스 규율을 적용하면 탐지 관리가 규칙 조정 중심의 사후 대응에서 지속적인 탐지 개선 프로세스로 전환됩니다.
문제 해결 및 복구
일반적인 문제와 그 해결책은 다음과 같습니다.
- 예기치 못한 삭제: 상태 백엔드 구성을 확인해야 합니다.
- 인증 오류: OIDC 및 API secrets를 확인해야 합니다.
변동 경고: Sumo Logic UI에서 수작업으로 수정이 이루어지지 않았는지 확인해야 합니다.
롤백: 커밋을 되돌리고 다시 적용합니다. 테라폼 상태는 완전한 복구를 보장합니다.
의미: 이러한 보호 장치는 탐지 엔지니어링을 탄력적으로 만들며 실수가 위기가 아닌 학습 기회가 되도록 합니다.
중요 참고 사항
Sumo Logic은 클라우드 SIEM 서비스, 해당 API, 그리고 클라우드 SIEM 서비스 내 규칙 및 기타 구성과 관련된 공개된 테라폼 리소스에 대한 지원 및 유지 관리에만 책임이 있습니다. 고객은 자체 GitHub 리포지토리와 그 안에서 이루어지는 보안 및 프로세스에 대한 지원 및 유지 관리에 책임이 있습니다. 이 가이드는 보증 없이 제공되며 리포지토리 설정 및 운영이 조직의 모든 요구 사항을 충족하는지 확인하는 책임은 사용자에게 있습니다.
프로세스에서 실행으로
GitHub에서 클라우드 SIEM 규칙을 관리하는 것은 수작업에 의존한 조정 중심의 운영에서 측정 가능한 개선으로 이동하는 중요한 전환점이 됩니다. 버전 관리, 자동화, CI/CD를 통해 모든 탐지는 살아 있는 시스템의 일부가 되어 학습하고 적응하며 개선합니다.
Sumo Logic 클라우드 SIEM을 기반으로 하는 이 시스템은 지능형 보안 운영으로 발전하여 탐지가 컨텍스트와 연결되고 컨텍스트가 조치로 이어져 마침내 결과를 만들어 냅니다.
녹화된 데모를 통해 SIEM 기능을 직접 확인해 보세요.
