[AWS Hardening 15] 접근부터 복구까지, AWS 점검 흐름 완성하기

About this offer

작은 주문 조회 서비스가 새 버전으로 배포됐다고 가정해 보겠습니다. 화면은 열리고 주문 번호도 조회됩니다. 담당자는 이어서 로그인 경로, 파일 접근 권한, 통신 규칙, 감사 기록과 복구 준비를 확인합니다. 이 결과를 한곳에 모으면 이번 변경에서 무엇을 확인했는지 설명할 수 있습니다. AWS는 서버와 저장소 등을 제공하는 클라우드 서비스입니다. Hardening은 공격과 실수에 견디도록 설정과 운영 절차를 강화하는 과정입니다. 이번 글은 AWS Hardening 15편의 마무리입니다. 앞선 글에서 다룬 보호 조건을 서비스 하나의 점검 흐름으로 연결합니다. 맡은 범위를 먼저 적습니다 AWS와 사용자는 보안의 책임을 나눠 맡습니다. 선택한 서비스에 따라 사용자가 관리할 범위가 달라집니다. EC2 같은 가상 서버에서는 설치한 운영체제와 애플리케이션, 통신 설정을 관리합니다. S3 같은 파일 저장 서비스에서도 데이터와 접근 권한의 관리가 필요합니다. AWS Shared Responsibility Model 점검 대상에는 서비스 이름, AWS 계정, Region, 사용한 자원과 담당자를 적습니다. Region은 AWS 서비스를 사용하는 지역 단위입니다. Resource는 서버나 저장소처럼 AWS에서 관리하는 대상을 뜻합니다. 한 지역의 검사 결과를 다른 지역에도 적용하려면 그곳의 설정과 동작을 확인해야 합니다. 여기서는 설명용 서비스 study-orders 를 사용합니다. 실제 계정 정보와 고객 데이터는 사용하지 않습니다. 사용자는 주문을 조회하고, 애플리케이션은 필요한 파일을 읽고, 운영자는 배포와 복구를 담당한다고 가정합니다. 이 세 주체가 필요한 작업을 각각 정하면 검사할 경계도 구체적으로 고를 수 있습니다. 1편부터 10편까지의 설정을 동작으로 확인합니다 로그인과 권한 1편에서는 MFA와 임시 자격 증명을 다뤘습니다. MFA는 로그인할 때 추가 인증을 요구하는 방식입니다. 임시 자격 증명에는 사용할 수 있는 시간이 정해집니다. 실제 로그인에서 추가 인증이 요구되는지, 역할을 맡은 뒤 필요한 조회가 가능한지, 정한 세션 처리 조건이 적용되는지 확인합니다. 세션은 발급받은 자격 증명으로 작업하는 기간입니다. 2편의 IAM은 누가 어떤 작업을 할 수 있는지 관리합니다. Role은 작업 권한을 담는 역할입니다. Trust Policy는 그 역할을 맡을 주체를 정하고 Permission Policy는 수행할 작업을 정합니다. 주문 조회 역할의 필요한 읽기 요청과 제한한 삭제 요청을 따로 확인합니다. 대상 자원에 연결된 정책도 함께 살펴봅니다. 네트워크와 서버 관리 3편에서는 VPC, Subnet과 Security Group을 살펴봤습니다. VPC는 AWS 안에서 사용하는 가상 네트워크이고, Subnet은 그 안에서 나눈 구역입니다. Security Group은 허용할 통신을 정합니다. 주문 조회 애플리케이션에서 데이터베이스로 연결되는 경로와 제한한 출처의 연결 결과를 함께 기록합니다. 4편에서는 EC2의 관리 연결과 IMDSv2를 구분했습니다. EC2는 가상 서버입니다. IMDSv2는 서버가 자신의 정보와 역할 자격 증명에 접근할 때 사용하는 경로입니다. 먼저 세션 Token을 발급받고 그 값으로 정보를 요청합니다. Token은 요청에 함께 보내는 값입니다. 운영자의 관리 접속이 정상 동작하는지, 애플리케이션의 정보 요청이 이 조건에서 동작하는지 확인합니다. 설치한 운영체제와 애플리케이션의 보안 업데이트도 해당 담당자가 관리합니다. 데이터와 실행 주체 5편의 S3에서는 파일의 공개 접근, 객체 소유권, 전송 보호를 확인했습니다. Bucket은 파일을 담는 저장 공간이고 객체는 그 안의 파일 단위입니다. 주문 보고서가 필요한 역할에만 제공되는지, 정한 보호 조건으로 파일을 주고받는지 확인합니다. 6편에서는 Secrets Manager와 KMS를 연결했습니다. Secrets Manager는 비밀번호 같은 비밀을 저장하고 KMS는 암호화 Key를 관리합니다. KMS Key는 암호화 작업과 사용 권한을 관리하는 자원입니다. 비밀을 읽는 권한과 복호화 권한을 확인합니다. 복호화는 암호화된 내용을 다시 읽을 수 있게 하는 과정입니다. 비밀번호를 교체했다면 기존 연결과 새 연결의 결과도 살펴봅니다. 8편의 RDS에서는 데이터베이스 접속, 전송 보호와 복원 조건을 확인했습니다. RDS는 데이터베이스 운영을 돕는 서비스입니다. 별도 시험 환경에서 데이터를 복원하고 내용, 연결 권한과 서비스 조회를 검사합니다. 암호화 Key의 유지와 사용 권한도 복구 계획에 넣습니다. 9편의 EKS에서는 애플리케이션의 AWS 권한과 운영자의 Cluster 접근을 나눴습니다. Kubernetes는 컨테이너 애플리케이션을 배치하고 관리하는 도구입니다. 컨테이너는 프로그램을 실행하는 격리된 환경입니다. EKS는 Kubernetes를 운영하는 서비스이고 Cluster는 함께 구성된 서버와 관리 요소의 묶음입니다. 애플리케이션이 필요한 AWS 작업을 수행하는지, 운영자는 승인한 경로에서 관리 요청을 수행하는지 각각 확인합니다. 기록과 조직 규칙 7편의 CloudTrail은 AWS 활동 기록을 다룹니다. GuardDuty는 의심스러운 활동의 탐지 결과를 제공합니다. 점검에서는 필요한 종류의 기록이 보관되는지, 경고가 담당자에게 전달되는지, 기록 조회와 후속 조치가 이어지는지 살펴봅니다. 10편에서는 Organizations의 SCP와 설정 점검을 연결했습니다. Organizations는 여러 계정을 묶어 관리합니다. SCP는 적용 대상 계정의 권한 상한을 제한하는 규칙입니다. 실제 작업에는 필요한 IAM 권한도 있어야 합니다. AWS Config는 자원 설정을 기록하고 정한 기준에 맞는지 평가합니다. Security Hub CSPM은 보안 설정을 점검하고 결과를 모아 보여 줍니다. 점검 결과는 대상 계정, Region, 수집 범위와 함께 읽습니다. 예외에는 담당자, 이유와 재검토 조건을 적습니다. 11편부터 14편까지 운영 과정에 연결합니다 11편에서는 IAM Access Analyzer의 결과를 읽고 접근 권한을 다시 검토했습니다. Analyzer는 정한 범위에서 접근을 분석하는 도구입니다. 결과에 나온 공유가 업무상 필요한지 확인하고, 정책 변경 뒤의 분석 결과와 실제 업무 요청을 기록합니다. 주기적으로 실행하는 작업도 사용 기간에 포함해 검토합니다. 12편에서는 AWS Backup의 보존 조건과 복원 시험을 연결했습니다. Backup은 복구에 사용할 사본을 관리하는 작업입니다. 보존 기간과 삭제 보호 조건을 검토하고, 복원한 데이터와 애플리케이션의 결과를 따로 확인합니다. 복원 시험의 판정과 시험 자원의 정리 상태까지 기록합니다. 13편에서는 CloudFormation의 Drift와 Change Set을 다뤘습니다. CloudFormation은 설정 파일로 AWS 자원을 관리합니다. Drift는 설정 파일과 실제 자원 사이의 차이이고, Change Set은 실행할 변경 내용을 검토하는 목록입니다. 바뀔 속성, 자원 교체 여부와 복구 계획을 확인하고 승인된 범위에서 변경 결과를 검사합니다. 14편에서는 합성 사건 기록으로 Incident Drill의 대응 순서를 검사했습니다. Incident Drill은 사고 상황을 가정해 대응 흐름을 점검하는 활동입니다. 조사 기록을 보존하고 조치 범위를 승인받습니다. 필요한 제한을 적용한 뒤 서비스와 데이터의 복구 결과를 확인합니다. 연습에서 발견한 빠진 단계에는 담당자와 다음 점검 조건을 남깁니다. 한 번의 변경에 다섯 단계의 증거를 남깁니다 대상과 담당자 정하기 → 접근과 통신 확인 → 데이터와 기록 확인 → 변경과 복구 검사 → 결과와 다음 점검 남기기 그림은 서비스 변경을 검토할 때 사용할 운영 절차의 제안입니다. 각 단계의 실행과 연결은 해당 환경에 맞게 준비합니다. 실제 결과도 그 환경에서 얻습니다. 확인할 항목이 남아 있으면 담당자와 추가 확인 조건을 기록합니다. 질문 남길 결과 누가 어떤 작업을 하나요? 주체, 대상, 필요한 요청의 성공과 제한 요청의 거절 어느 경로로 연결하나요? 허용한 출처의 연결과 제한한 출처의 결과 데이터와 기록을 어떻게 지키나요? 접근 범위, 수집 대상과 실제 보관 결과 변경 실패 때 어떻게 복구하나요? 복구할 설정과 데이터, 실제 조회 결과와 소요 시간 언제 다시 확인하나요? 담당자, 다음 검토일과 변경 시 재검토할 조건 예를 들어 주문 조회는 성공했는데 새 백업에서 주문 한 건이 누락됐다고 가정해 보겠습니다. 점검 기록에는 조회 성공과 데이터 누락을 함께 적습니다. 복구 항목은 확인이 더 필요한 상태로 남깁니다. 같은 화면에 결과가 모여 있어도 각 결과의 대상과 확인 조건을 읽어야 합니다. 합성 기록에서 확인이 필요한 항목을 골라 봅니다 JavaScript는 프로그램의 동작을 적는 언어이고 Node는 이 코드를 실행하는 도구입니다. 아래 코드는 실제 AWS에 접속하지 않는 로컬 예제입니다. 필수 항목마다 담당자와 증거 표시가 정확히 한 개 있는지 검사합니다. 기록이 빠지거나 중복되면 해당 항목을 보류합니다. READY는 이 기록 형식이 채워졌다는 뜻이고 HOLD는 추가 확인할 기록이 있다는 뜻입니다. const expected = ["access", "network", "data", "audit", "recovery"]; const rows = expected.map((id) => ({ id, owner: "study-team", evidence: id === "recovery" ? "" : "synthetic-result", })); function review(records) { const pending = expected.filter((id) => { const matches = records.filter((row) => row.id === id); return ( matches.length !== 1 || typeof matches[0].owner !== "string" || !matches[0].owner.trim() || typeof matches[0].evidence !== "string" || !matches[0].evidence.trim() ); }); return { state: pending.length ? "HOLD" : "READY", pending }; } console.log(JSON.stringify(review(rows))); const complete = rows.map((row) => ({ ...row, evidence: "synthetic-result", })); console.log(JSON.stringify(review(complete))); Node v24.13.1에서 실행한 출력은 다음과 같습니다. {"state":"HOLD","pending":["recovery"]} {"state":"READY","pending":[]} 첫 입력에는 recovery의 증거 표시가 비어 있습니다. 함수는 복구 기록에 추가 확인이 필요하다고 표시합니다. 다음 입력에서는 합성 증거 표시를 채웠으므로 READY가 나옵니다. 누락, 중복, 공백 담당자와 공백 증거 표시를 넣은 추가 입력에서도 보류 판정을 확인했습니다. 이 예제는 입력 기록을 검사합니다. 실제 IAM 권한, 네트워크 통신, 데이터 복원과 로그 전달은 실행하지 않았습니다. 증거 표시의 문자열은 기록 유무를 나타냅니다. 운영 점검에서는 사용한 요청, 대상, 시각, 기대 결과와 실제 결과를 담당자가 확인해야 합니다. 바뀐 조건에서 다시 검토합니다 AWS의 보안 점검 가이드는 정기 검토와 함께 조직 구성, 사용 서비스와 애플리케이션이 바뀌는 상황의 재검토를 설명합니다. 접근이 의심되는 상황에서도 관련 설정을 살펴봅니다. 점검표에는 정기 일정과 변경 시 다시 볼 항목을 함께 남길 수 있습니다. AWS security audit guidelines 점검 결과를 기록할 때는 비밀번호, 자격 증명과 고객 정보의 원문을 제외합니다. 필요한 요약과 승인된 증거 위치를 남기고 기록을 읽을 권한도 정합니다. 담당자가 바뀌면 다음 담당자가 같은 범위와 결과를 따라갈 수 있는지 확인합니다. AWS Hardening 전체 목록 [AWS Hardening 01] 관리자 Login부터 줄이기: MFA와 임시 자격 증명 [AWS Hardening 02] 역할을 맡을 수 있는 사람과 할 수 있는 작업: IAM 최소 권한 [AWS Hardening 03] 같은 VPC니까 안전할까요? 보안 Group과 Subnet 경계 [AWS Hardening 04] SSH를 열기 전에: EC2 관리 경로와 IMDSv2 [AWS Hardening 05] 암호화된 Bucket도 공개될 수 있습니다: S3 접근 경계 [AWS Hardening 06] 비밀을 저장했는데도 읽을 수 있나요? KMS와 Secrets Manager [AWS Hardening 07] 경고를 켰는데 누가 볼까요? CloudTrail 감사와 대응 경로 [AWS Hardening 08] RDS를 비공개로 만들면 끝일까요? 연결 보호와 복원 검증 [AWS Hardening 09] EKS의 두 권한 경계: Pod의 AWS 접근과 API Server 접근 [AWS Hardening 10] 한 번 설정하고 끝내지 않기: SCP와 지속적인 보안 점검 [AWS Hardening 11] IAM Access Analyzer로 접근 권한을 다시 확인하기 [AWS Hardening 12] AWS Backup으로 보존과 복원 시험 연결하기 [AWS Hardening 13] CloudFormation 변경 전에 Drift와 영향 확인하기 [AWS Hardening 14] Incident Drill에서 조사와 복구를 연습하기 [AWS Hardening 15] 접근부터 복구까지, AWS 점검 흐름 완성하기 — 현재 글 확인 문제와 해설 S3 파일의 암호화 설정을 확인했습니다. 주문 보고서의 접근 경계를 확인하려면 어떤 결과가 더 필요할까요? CloudFormation의 변경 목록을 읽었습니다. 변경 완료를 확인할 때 무엇을 이어서 검사할까요? 합성 함수에서 READY가 나왔습니다. 실제 복구 성공을 기록하려면 어떤 증거가 필요할까요? 해설 필요한 역할의 읽기 성공과 제한한 역할의 거절 결과를 확인합니다. 관련 정책과 실제 요청 조건을 함께 남깁니다. 저장 암호화와 접근 권한은 각각 확인합니다. 실제로 실행한 변경의 결과와 서비스 동작을 검사합니다. 영향받은 권한과 통신 경로도 살펴보고, 데이터 이전이 있었다면 내용과 복구 조건을 확인합니다. 선택한 복구 지점, 복원 대상, 데이터 내용, 애플리케이션 조회, 접근 조건과 걸린 시간을 남깁니다. READY는 사람이 넣은 기록의 형식 판정입니다. 복습과 마무리 지금은 익숙한 서비스 하나에 다섯 질문을 적용해 기대 결과를 적어 보세요. 하루 뒤에는 증거 한 개가 빠진 상황을 가정하고 담당자와 추가 확인 조건을 써 보세요. 일주일 뒤에는 역할, Region 또는 백업 구성이 바뀐 상황에서 다시 검사할 항목을 골라 보세요. 이 일정은 복습 제안입니다. AWS Hardening 15편은 로그인과 권한에서 시작해 네트워크, 데이터, 기록, 조직 규칙, 변경 검증과 복구로 이어졌습니다. 마무리에 남길 것은 확인한 범위와 결과를 다시 읽을 수 있는 기록입니다. 다음 변경에서도 같은 질문을 사용하고, 달라진 조건에 필요한 검사를 이어갑니다. 공식 문서 검토일: 2026-10-06. 점검 흐름과 합성 기록 예제는 이 시리즈를 연결하기 위해 작성했습니다.