1. 기존 데이터베이스 접근 관리의 문제점
대부분의 조직에서 데이터베이스 접근은 아직도 수동으로 관리됩니다. 임시 작업을 위해 부여한 접근 권한이 영구적으로 남아 있거나, 담당자가 퇴사한 후에도 자격 증명이 유효한 상태로 남아 있는 경우가 많습니다.
| 문제 | 구체적 위험 |
|---|---|
| 잊혀진 자격 증명 | 임시 작업을 위해 부여된 접근 권한이 무기한 유지됨 |
| 과도한 권한 | 작업 완료 후에도 사용자가 권한을 계속 보유함 |
| 늦은 위협 탐지 | 비인가 활동이 감사 시점에야 발견됨 |
| 수동 로그 분석 | 보안팀이 CloudWatch 로그를 수주간 검토해야 함 |
| 내부자 위협 | 정상적인 세션 중 악성 활동이 탐지되지 않고 진행됨 |
JIT(Just-in-Time) 접근 제어는 이 문제를 근본적으로 해결합니다. 영구적인 데이터베이스 자격 증명을 없애고, 필요할 때만 시간이 제한된 임시 자격 증명을 발급합니다. autobotAI는 Amazon Bedrock의 AI 모델을 활용해 이 전 과정을 자동화합니다.
2. AI 에이전트 아키텍처
이 모듈의 봇은 5개의 전문화된 AI 에이전트로 구성됩니다. 각 에이전트는 접근 생명주기의 특정 단계를 담당합니다.
| 에이전트 | 약칭 | 역할 |
|---|---|---|
| Validation Agent | Val | 사용자 신원, IP 평판, 접근 요건 검증 |
| Evaluation Agent | Eva | 위험 평가 및 승인 경로 결정 (자동 vs. 수동) |
| Grant Agent | Grant | 정확한 권한으로 임시 자격 증명 발급 |
| Revocation Agent | Rev | 지정된 시간 후 자동으로 접근 권한 회수 |
| Analysis Agent | Ana | 사용자 활동 검토 및 컴플라이언스 보고서 생성 |
이 모듈에서는 두 가지 역할을 번갈아 수행하며 JIT 워크플로 전체를 경험합니다.
| 역할 | 주요 업무 |
|---|---|
| 보안 관리자 (Security Admin) | JIT 봇 설정, AI 모델 구성, 고위험 요청 검토 및 승인, 보안 보고서 모니터링 |
| DBA (데이터베이스 관리자) | 임시 데이터베이스 접근 요청, 신원 검증 정보 제공, 데이터베이스 연결 및 쿼리 실행 |
3. JIT 워크플로 아키텍처
JIT 데이터베이스 접근 아키텍처는 6개 레이어로 구성됩니다.
| 레이어 | 구성 요소 | 역할 |
|---|---|---|
| 요청 레이어 | 채팅 인터페이스 | 자연어 처리로 사용자 요구 파악, 초기 파라미터 수집 |
| AI 분석 레이어 | Val, Eva (Amazon Bedrock) | 신원 검증, IP 평판 확인, 위험 수준 평가, 승인 경로 결정 |
| 자격 증명 발급 레이어 | Grant, AWS IAM | 시간이 제한된 임시 자격 증명 생성 및 안전한 전달 |
| 회수 레이어 | Rev, 보안 그룹 | 접근 시간 모니터링, 기간 만료 후 자동 자격 증명 삭제 |
| 분석 레이어 | Ana, CloudWatch | 데이터베이스 활동 로그 검토, AI 활동 보고서 생성 |
| 감사 레이어 | CloudTrail, Amazon SES | 모든 접근 요청의 완전한 감사 추적, 보안팀 알림 발송 |
전체 워크플로 흐름:
사용자 접근 요청
│
▼
[Step 1: 검증] Val 에이전트 — IP 주소 + IAM 역할 + RDS 인스턴스 확인
│
▼
[Step 2: 위험 평가] Eva 에이전트 — 위험 점수 계산
│
├─ 저위험 (점수 낮음) ──► 자동 승인
│
└─ 고위험 (점수 높음) ──► 보안 관리자 수동 승인 요청
│
▼
승인 후 진행
│
▼
[Step 3: 자격 증명 발급] Grant 에이전트 — 임시 DB 사용자 생성 + IAM 정책
│
▼
사용자 데이터베이스 작업 수행
│
▼
[Step 4: 자동 회수] Rev 에이전트 — 지정 시간 후 자격 증명 삭제
│
▼
[Step 5: 활동 분석] Ana 에이전트 — CloudWatch 로그 분석 + 보고서 이메일 발송
4. 2.1 봇 가져오기 및 설정 (보안 관리자 역할)
사전 배포된 인프라 확인
다음 인프라는 이미 배포되어 있습니다.
- Amazon RDS MySQL 데이터베이스 클러스터
- 적절한 네트워킹이 구성된 VPC
- 데이터베이스 접근을 위한 보안 그룹
- Module 1에서 설정한 Amazon Bedrock, Amazon SES, AbuseIPDB, AWS 통합
Step 1. 라이브러리에서 봇 가져오기
- https://autobot.live/app#/library에 접속합니다.
- "Just In Time RDS Access Control"을 검색합니다.
- 봇을 선택하고 Import를 클릭합니다.
Step 2. 모든 에이전트 노드에 AI 모델 설정
워크플로 캔버스에서 다음 에이전트 노드 각각을 클릭하고 오른쪽 패널에서 설정합니다.
| 에이전트 노드 | Integration | AI 모델 |
|---|---|---|
| User Validation (Val) | AWS Bedrock 통합 선택 | us.anthropic.claude-sonnet-4-5-20250929-v1:0 |
| Risk Evaluator (Eva) | AWS Bedrock 통합 선택 | Meta.llama3-70b-instruct-v1:0 |
| Access Granting Agent (Grant) | AWS Bedrock 통합 선택 | us.anthropic.claude-sonnet-4-5-20250929-v1:0 |
| Access Revocation Agent (Rev) | AWS Bedrock 통합 선택 | us.anthropic.claude-sonnet-4-5-20250929-v1:0 |
| Activity Analysis Agent (Ana) | AWS Bedrock 통합 선택 | us.anthropic.claude-sonnet-4-5-20250929-v1:0 |
Meta.llama3-70b-instruct-v1:0을 사용하고, 나머지 4개 에이전트는 모두 Claude Sonnet 4.5를 사용합니다.
각 노드 설정 방법:
- 워크플로 캔버스에서 에이전트 노드(원형)를 클릭합니다.
- 오른쪽 패널 Integration에서 AWS Bedrock 통합을 선택합니다.
- AI 섹션에서 위 표에 맞는 모델을 선택합니다.
Step 3. 이메일 알림 설정
다음 4개의 알림 노드 각각에 Amazon SES를 설정합니다.
- Notify RDS Access Initiated for a User
- Notify RDS Access Approved for a High Risk User
- Notify User Activity and Revocation Status
- Approval Action
각 알림 노드 설정 방법:
- 워크플로 캔버스에서 알림 노드를 클릭합니다.
- 오른쪽 패널에서 설정합니다:
- Recipients: 필드 우측 상단에서 Events를 선택한 후 SES에서 인증한 이메일 주소를 직접 입력하고 Enter
- Service: SES
- Integration: Module 1에서 생성한 SES 통합 선택
- Action: Send Message using AWS SES
- Approval Action 노드에는 추가로 설정합니다:
- Number of required approvers: 1
- Approvers 섹션에서 Static을 선택하고 인증된 SES 이메일 자격 증명 선택
Step 4. 봇 저장 및 실행
- 우측 상단 Save를 클릭해 모든 설정 변경사항을 저장합니다.
- Run을 클릭해 봇 실행을 시작합니다.
- 우측 하단에 팝업이 나타납니다. 이것이 DBA가 AI 에이전트와 대화하는 채팅 인터페이스입니다.
설정 완료 요약
| 구성 요소 | 설정 내용 | 목적 |
|---|---|---|
| AI 에이전트 | 5개 에이전트 모두 Amazon Bedrock Claude Sonnet 4.5 사용 | 지능형 의사결정 |
| IP 검증 | AbuseIPDB 통합 | 요청자 IP 평판 검증 |
| AWS 서비스 | us-west-2 리전의 AWS 통합 (8개 액션 노드) | 자격 증명 발급 활성화 |
| 알림 | Amazon SES 이메일 경보 (4개 알림 포인트) | 접근 이벤트 실시간 통보 |
| 승인 | 필요 승인자 1명으로 수동 승인 워크플로 | 고위험 요청 검토 |
5. 2.2 저위험 시나리오 테스트 — 자동 승인
| 항목 | 내용 |
|---|---|
| 사용자 | Alice (데이터 엔지니어) |
| 목적 | 야간 배치 작업의 실패한 결제 거래 조사 |
| 위험 수준 | 낮음 (Low) |
| 예상 결과 | 자동 승인 |
사전 배포된 인프라 정보 확인
- AWS 콘솔에서 CloudFormation으로 이동합니다 (us-west-2).
cfn-으로 시작하는 워크샵 스택을 선택합니다.- Outputs 탭에서 다음 값을 확인합니다:
Module5JITVPCID— CloudShell용 VPC IDModule5JITSecurityGroupID— 보안 그룹 IDModule5JITRDSClusterEndpoint— 데이터베이스 엔드포인트
1.1 접근 요청 시작
- Run 클릭 후 우측 하단에 팝업이 나타나면 Open을 클릭합니다.
- Val 에이전트가 인사하며 검증 프로세스를 시작합니다.
- 채팅창에 "I need a database access."를 입력합니다.
1.2 신원 검증 완료
| 단계 | 입력 값 | 예상 결과 |
|---|---|---|
| IP 주소 | 현재 IP 주소 (브라우저에서 "my ip" 검색) | IP 안전 확인, 위험 점수 0/100 |
| IAM 역할 | WSParticipantRole | 역할 활성 및 유효 확인 |
| RDS 인스턴스 | cfn-jit-rds-access-writer | 인스턴스 목록에서 선택 |
| 데이터베이스 스키마 | workshop_db | 스키마 확인 |
| 접근 사유 | 아래 텍스트 참조 | 구체적이고 감사 가능한 이유 확인 |
| 접근 기간 | 10 minutes | 합리적인 기간 확인 |
접근 사유 입력 예시:
Need to reconcile failed payment transactions from overnight batch jobs. Investigating duplicate payment_id errors. Reference Incident INC-2024-5348.
1.3 자동 위험 평가
Eva(평가 에이전트)가 분석한 위험 요소:
| 위험 요소 | 평가 결과 |
|---|---|
| IP 평판 | 매우 안전 (2/100) |
| IAM 신원 | 검증됨 및 활성 상태 |
| 접근 시간 | 정상 업무 시간 |
| 접근 사유 | 구체적이고 감사 가능 |
| 요청 기간 | 합리적 (10분) |
| 위험 점수 | 15/100 → 저위험 → 자동 승인 |
1.4 임시 접근 자격 증명 수령
채팅 인터페이스에서 Grant 에이전트의 응답을 확인합니다. 다음 정보가 제공됩니다:
- 임시 데이터베이스 사용자 이름
- RDS IAM 인증을 위한 IAM 정책
- VPC 및 보안 그룹 정보
- IAM 토큰 생성이 포함된 MySQL 연결 명령어
- 유효 기간: 10분
1.5 데이터베이스 연결
- AWS 콘솔에서 AWS CloudShell을 엽니다.
- + 아이콘 → Create VPC Environment를 클릭합니다.
- 다음과 같이 설정합니다:
- Name:
test-env - VPC: Grant 에이전트가 제공한 VPC ID
- Security Group: Grant 에이전트가 제공한 보안 그룹 ID
- Subnet: 사용 가능한 서브넷 중 하나 선택
- Name:
- Create를 클릭합니다.
- Grant 에이전트가 제공한 MySQL 연결 명령어를 복사해 실행합니다.
1.6 데이터베이스 작업 수행
먼저 데이터베이스를 선택합니다:
USE workshop_db;
인가된 쿼리 실행:
-- 실패한 거래 조사
SELECT transaction_id, payment_id, customer_account_id, amount,
currency, status, error_code, created_at
FROM payment_transactions
WHERE status = 'FAILED'
AND created_at >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY created_at DESC;
-- 중복 결제 ID 분석
SELECT payment_id, COUNT(*) as occurrence_count, SUM(amount) as total_amount
FROM payment_transactions
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
GROUP BY payment_id
HAVING COUNT(*) > 1
ORDER BY occurrence_count DESC;
1.7 자동 접근 회수
Rev(회수 에이전트)가 자동으로 수행하는 작업:
- IAM 정책 삭제
- 임시 데이터베이스 사용자 삭제
- 컴플라이언스를 위한 CloudWatch 로그 아카이브
검증: 재연결 시도하면 ERROR 1045 (28000): Access denied가 표시됩니다.
1.8 활동 분석 검토
Ana(분석 에이전트)의 분석 결과:
- 모든 활동이 명시된 접근 목적과 일치
- 비인가 행위 미탐지
- 읽기 전용 작업만 수행
- 접근 회수 성공
완전한 활동 보고서가 이메일로 발송됩니다.
6. 고위험 시나리오 테스트 — 수동 승인
| 항목 | 내용 |
|---|---|
| 사용자 | Bob (데이터베이스 관리자) |
| 위치 | 런던 (상용 VPN 사용) |
| 목적 | 결제 게이트웨이 타임아웃 설정 업데이트 |
| 위험 수준 | 높음 (High) |
| 예상 결과 | 수동 승인 필요 |
2.1 고위험 요청 시작
| 단계 | 입력 값 | 예상 결과 |
|---|---|---|
| IP 주소 | 80.94.92.171 (고위험 IP) | IP 플래그 — 위험 점수 87/100 |
| 설명 | 아래 텍스트 참조 | 컨텍스트 검토 후 진행 |
| IAM 역할 | WSParticipantRole | 역할 확인 |
| RDS 인스턴스 | cfn-jit-rds-access-writer | 인스턴스 선택 |
| 스키마 | workshop_db | 스키마 확인 |
| 접근 사유 | 아래 텍스트 참조 | 프로덕션 결제 시스템 접근 사유 확인 |
| 기간 | 10 minutes | 기간 확인 |
VPN 사용 설명 입력 예시:
I'm in London for an emergency client escalation. Corporate VPN is down, using a commercial VPN.
접근 사유 입력 예시:
Need to update payment gateway timeout configuration to resolve production transaction failures.
2.2 위험 평가
Eva가 계산한 위험 요소:
| 위험 요소 | 평가 결과 |
|---|---|
| IP 평판 | 고위험 상용 VPN (87/100) |
| 지리적 위치 | 비정상 (런던) |
| 데이터베이스 스키마 | 프로덕션 결제 시스템 |
| 영향 범위 | 비즈니스 크리티컬 |
| 위험 점수 | 84/100 → 매우 높음 → 수동 승인 필요 |
2.3 보안 운영 검토 및 승인
- 승인자 이메일 받은 편지함을 확인합니다.
- 승인 요청 세부 정보를 검토합니다.
- 다음 사항을 확인합니다:
- 사용자 재직 상태 및 역할
- 비즈니스 사유 타당성
- 관리자 승인 (Sarah Chen이 CHG-2024-8821 승인)
- 변경 요청 유효성
- 이메일 또는 플랫폼에서 승인 인터페이스를 엽니다.
- Take Action을 클릭합니다.
- 플래그된 리소스를 선택합니다.
- 승인 메시지를 입력하고 제출합니다.
2.4 조건부 접근 수령
승인 후 Grant가 강화된 모니터링과 함께 접근을 제공합니다:
- 모든 쿼리에 추가 로깅 적용
- 실시간 이상 탐지 활성화
- 결제 시스템 변경 사항 즉시 감사
2.5 인가된 작업 수행
USE workshop_db;
-- 현재 설정 검토
SELECT gateway_name, timeout_seconds, retry_attempts,
last_modified, modified_by
FROM payment_gateway_config
WHERE gateway_name = 'PRIMARY_PROCESSOR';
-- 타임아웃 설정 업데이트
UPDATE payment_gateway_config
SET timeout_seconds = 30,
retry_attempts = 5,
last_modified = NOW(),
modified_by = 'bob_emergency_change_CHG-2024-8821'
WHERE gateway_name = 'PRIMARY_PROCESSOR';
-- 변경 사항 확인
SELECT gateway_name, timeout_seconds, retry_attempts,
last_modified, modified_by
FROM payment_gateway_config
WHERE gateway_name = 'PRIMARY_PROCESSOR';
2.6 (선택) 비인가 활동 탐지 테스트
-- 시도 1: 비인가 고객 계정 접근
SELECT customer_account_id, account_holder_name,
account_balance, credit_limit
FROM customer_accounts
WHERE account_balance > 1000000
ORDER BY account_balance DESC LIMIT 20;
-- 시도 2: 비인가 결제 데이터 접근
SELECT transaction_id, customer_account_id,
card_number_last4, amount, merchant_name
FROM payment_transactions
WHERE amount > 50000
AND created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
ORDER BY amount DESC;
이 쿼리는 실행되지만 고도로 의심스럽고 비인가된 행위로 기록됩니다.
2.7 강화된 활동 분석 검토
인가된 활동:
- 설정 검토: 인가됨
- CHG-2024-8821에 따른 타임아웃 조정: 인가됨
- 변경 확인: 인가됨
탐지된 비인가 활동:
- 높은 심각도: 고객 계정 열거 (20개 계정, $4,730만 노출)
- 높은 심각도: 결제 데이터 유출 시도 (43건 거래, $420만)
분석 결과 — 심각한 보안 경보:
사용자는 인가된 작업을 완료했지만 비인가 접근 패턴을 시도했습니다.
즉각 취해진 조치:
- 접근 자동 회수
- 모든 비인가 쿼리 기록
- 관리자 통보
- 컴플라이언스 팀 경보
권장 후속 조치:
- 보안 인터뷰 실시
- 90일간 접근 기록 검토
- 필수 보안 교육 이수
- 조사 완료 전까지 접근 정지 고려
완전한 세션 타임라인과 포렌식이 포함된 상세 보안 경보 이메일이 발송됩니다.
7. 핵심 정리
이 모듈에서 배운 것
| 학습 내용 | 설명 |
|---|---|
| AI 기반 접근 관리 | AI 에이전트가 검증부터 회수까지 데이터베이스 접근의 전체 생명주기를 자동화하는 방법 |
| 위험 기반 의사결정 | Eva 에이전트가 위험 요소를 평가해 자동 vs. 수동 승인 경로를 결정하는 방법 |
| 제로 스탠딩 권한 | 영구적인 자격 증명 대신 시간이 제한된 임시 접근을 부여하는 원칙 |
| 지능형 모니터링 | Ana 에이전트가 데이터베이스 활동을 검토하고 비인가 행위를 실시간으로 탐지하는 방법 |
| 내부자 위협 탐지 | 정상적인 접근 세션 중에도 데이터 유출 시도를 식별하는 시스템 능력 |
| 자동화된 컴플라이언스 | 감사 및 인시던트 대응을 위한 완전한 감사 추적이 자동으로 생성되는 방법 |
주요 보안 이점
| 이점 | 설명 |
|---|---|
| 제로 스탠딩 권한 | 영구적인 데이터베이스 자격 증명이 존재하지 않음 |
| 자동화된 위험 평가 | 모든 요청이 복수의 위협 지표에 대해 평가됨 |
| 실시간 모니터링 | 비인가 활동이 즉시 탐지되고 기록됨 |
| 완전한 감사 추적 | 컴플라이언스 및 조사를 위한 전체 포렌식 제공 |
| 마찰 없는 보안 | 강력한 보안 통제를 유지하면서 정상 업무는 신속히 진행 |
| 내부자 위협 탐지 | 정상적인 세션 중에도 데이터 유출 시도를 식별 |
주요 문제 해결
| 문제 | 해결 방법 |
|---|---|
| 봇이 라이브러리에서 검색되지 않음 | "Just In Time RDS" 또는 "JIT RDS"로 검색 |
| AI 모델이 드롭다운에 없음 | Amazon Bedrock 통합이 활성 상태인지, 모델 접근 권한이 활성화되어 있는지 확인 |
| Run 클릭 후 채팅 인터페이스가 나타나지 않음 | 우측 하단 작은 팝업에서 "Open"을 클릭 |
| CloudShell VPC 환경 생성 실패 | CloudFormation Outputs에서 올바른 VPC ID 사용, 퍼블릭 서브넷 선택, 다른 가용 영역 시도 |
| MySQL 연결 명령어 실패 | 데이터베이스 엔드포인트 확인, 임시 사용자 생성 확인, 30초 후 재시도 (IAM 인증 토큰 활성화 대기) |
| 시간 만료 후 접근이 회수되지 않음 | 자동으로 처리됨. 채팅 인터페이스에서 Rev 에이전트의 확인 메시지 확인 |
| 승인 이메일이 수신되지 않음 | 스팸 폴더 확인, SES 이메일 자격 증명 인증 상태 확인, 알림 노드 설정 확인 |
Module 2 완료 기준
| 완료 항목 | 역할 |
|---|---|
| JIT 접근 봇 가져오기 및 설정 완료 | 보안 관리자 |
| 저위험 자동 승인 워크플로 테스트 성공 | DBA |
| CloudShell로 데이터베이스 연결 성공 | DBA |
| 샘플 쿼리 실행 성공 | DBA |
| 10분 후 접근 자동 회수 확인 | DBA |
| 활동 분석 이메일 수신 | 보안 관리자 |
| 고위험 접근 요청 시작 | DBA |
| 고위험 요청 검토 및 승인 | 보안 관리자 |
| 승인 후 인가된 작업 완료 | DBA |
| 분석 보고서에서 비인가 활동 탐지 확인 | 보안 관리자 |
다음 단계
Module 2에서 AI 에이전트를 활용한 JIT 데이터베이스 접근 제어를 완료했습니다. 다음 편에서는 Module 3: GuardDuty와 autobotAI를 이용한 위협 완화 및 인시던트 대응과 Module 4: Security Hub 에이전틱 자동 교정을 다룹니다. GuardDuty가 탐지한 RDS, EC2, IAM 보안 위협에 AI가 자동으로 대응하는 방법을 살펴봅니다.
