Loading the catalog…
Loading the catalog…
급한 문제를 해결하려고 서버 설정을 바꾼 상황을 가정해 보겠습니다. 서비스는 다시 동작합니다. 다음 배포 전에는 코드와 실제 값의 차이를 확인합니다. 이 차이가 변경 검토의 입력입니다. CloudFormation은 AWS Resource, 즉 서버와 저장소 같은 대상을 문서로 정의하고 배포하는 서비스입니다. 정의 문서는 Template이고 함께 관리하는 묶음은 Stack입니다. IaC는 구성을 코드로 관리하는 방식입니다. 앞선 조직 점검 편의 IaC를 변경 미리보기, 교체 영향, 실행 후 검증으로 연결하겠습니다. Drift는 기대한 값과 실제 값의 차이입니다 Drift는 Template과 Parameter에 적힌 기대 상태가 실제 Resource 상태와 달라진 상태입니다. Parameter는 Template에 전달하는 입력값입니다. 예를 들어 Template에 설정한 속성이 true 인데 운영 중 false 로 바뀌었다면 확인할 차이가 생깁니다. Drift Detection은 지원되는 Resource의 기대 값과 실제 값을 비교합니다. 담당자는 변경 항목과 시각, 이유를 확인합니다. 긴급 조치로 바뀐 값은 유지 또는 복구할 상태를 정하고 이유를 기록합니다. 검사 범위에는 조건이 있습니다. Template이나 Parameter에 명시한 속성이 비교 대상입니다. 기본값에 맡긴 속성은 추적할 값을 명시했는지 확인합니다. 지원되지 않는 Resource는 NOT_CHECKED 로 표시됩니다. IN_SYNC 는 검사한 지원 대상이 기대 상태와 맞는다는 뜻입니다. 지원 대상이 없는 Stack도 이 상태가 될 수 있으므로 검사한 항목을 함께 봅니다. CloudFormation Drift Detection 문서 에서 상태와 범위를 확인할 수 있습니다. Nested Stack과 확인할 속성을 적습니다 Nested Stack은 다른 Stack 안에 연결된 하위 Stack입니다. 상위 Stack의 Drift 검사에서 하위 Stack의 내부까지 자동으로 검사하는 범위는 제외됩니다. 하위 Stack을 직접 검사하고 결과를 연결합니다. 지원되는 속성과 별도로 확인할 항목도 목록에 남깁니다. 현재 식별값도 기록합니다. 같은 이름으로 다시 만든 Resource를 구분하기 위해서입니다. 검사 후 추가 변경이 생기면 자료를 갱신합니다. 이 글의 연습안은 검사 결과, 변경 이유, 담당자, 하위 Stack을 함께 관리합니다. Change Set 생성과 실행을 연결합니다 Change Set은 제안한 변경으로 어떤 Resource가 추가, 수정, 삭제될지 보여 주는 미리보기입니다. 수정한 Template이나 입력값을 제출해 생성하고 내용을 검토합니다. 생성 단계에서는 제안한 변경으로 Stack의 Resource를 갱신하는 작업이 진행되지 않습니다. 실행 단계에서 해당 변경이 적용됩니다. 검토에는 Resource 이름, 변경할 속성, 교체 가능성, 연결된 서비스, 복구 방법을 붙입니다. 성공적인 미리보기 생성 뒤에도 실행 중 실패가 생길 수 있습니다. 예를 들어 사용자 정의 Resource의 실행 동작은 별도 조건을 가질 수 있습니다. 생성 시 검사와 실행 결과를 각각 확인합니다. Change Set 공식 문서 가 이 순서와 한계를 설명합니다. 승인 기록에는 Change Set ID, 생성 시각, 검토 범위와 담당자를 적습니다. 검토 후 실제 값이 바뀌면 영향을 다시 확인합니다. 현재 상태를 반영하는 미리보기도 확인합니다 현재 문서에는 Drift-aware Change Set이 있습니다. 이 방식은 실제 상태, 이전 배포의 정의, 새 정의를 함께 비교합니다. 긴급 조치로 바꾼 값이 다음 배포에서 어떻게 처리될지 확인하는 데 도움이 됩니다. 검사한 값을 새 정의에 반영하는 선택도 검토할 수 있습니다. 지원 범위를 함께 확인해야 합니다. 지원되지 않는 Resource 유형과 Write-only 속성은 이전 배포 값을 활용하는 비교 범위가 있습니다. Write-only는 입력은 받으며 실제 값을 조회해 반환하는 범위가 제한된 속성입니다. AWS가 관리하도록 설정한 속성은 새 Template에서 바꾸지 않은 경우 실제 값을 유지하는 동작도 있습니다. 변하지 않는 속성의 Drift 조정에는 제한이 있습니다. Drift-aware Change Set 문서 의 지원 유형과 속성 조건을 확인합니다. Replacement에는 데이터와 연결 영향이 붙습니다 Replacement는 기존 Resource를 새 Resource로 교체하는 갱신 방식입니다. 새 Resource에는 새 Physical ID, 즉 실제 대상 식별값이 생깁니다. 일반적으로 새 대상을 만들고 의존하는 Resource의 참조를 연결한 뒤 기존 대상을 정리합니다. 속성마다 갱신 방식이 정해져 있으므로 변경할 속성의 공식 정의도 확인합니다. Resource Update Behavior 문서 가 갱신 방식을 설명합니다. 데이터가 들어 있는 대상은 보존할 자료와 새 대상의 동작까지 계획합니다. UpdateReplacePolicy 는 교체되는 이전 Resource를 삭제, 보존하거나 지원 유형에서 Snapshot을 만드는 방식을 정합니다. Snapshot은 특정 시점의 데이터를 복원할 수 있게 만든 자료입니다. 보존한 대상과 Snapshot에는 비용이 이어질 수 있습니다. UpdateReplacePolicy 문서 에서 지원 조건을 확인합니다. 보존 설정과 데이터 이동은 각각 확인합니다. 복구 자료의 시점, 복원 시험, 새 대상의 읽기와 쓰기, 연결 주소를 계획에 적습니다. 실패 시 되돌릴 구성과 데이터도 확인합니다. 그림은 현재 상태, 미리보기, 교체 영향, 실행 승인, 실제 검증을 연결합니다. 마지막에는 변경 결과와 서비스 요청을 확인합니다. 변경 검토를 위한 개념 그림입니다. JavaScript는 프로그램의 동작을 적는 언어이고 Node.js는 이 코드를 실행하는 도구입니다. 작은 Node.js 예제로 검토 기록을 확인합니다 아래 코드는 이 글의 연습 계획을 검사합니다. driftAt 은 현재 상태 확인 시각, previewAt 은 미리보기 생성 시각입니다. 담당자와 증거 ID가 있으며 확인 순서가 맞는지 계산합니다. 교체가 예정되면 복구 자료 검토 기록도 요구합니다. 필드 이름은 설명용 연습 양식입니다. change-review.mjs 로 저장하고 node change-review.mjs 로 실행할 수 있습니다. 예제는 합성 객체를 읽어 결과를 출력합니다. function review(plan) { const drift = Date.parse(plan.driftAt); const preview = Date.parse(plan.previewAt); const ready = typeof plan.owner === "string" && plan.owner.trim().length > 0 && typeof plan.evidenceId === "string" && plan.evidenceId.length > 0 && plan.nestedReviewed === true && typeof plan.replacement === "boolean" && Number.isFinite(drift) && Number.isFinite(preview) && drift <= preview && (!plan.replacement || plan.recoveryReviewed === true); return ready ? "READY_FOR_REVIEW" : "HOLD"; } const base = { owner: "operator-demo", evidenceId: "evidence-demo", nestedReviewed: true, replacement: true, recoveryReviewed: true, driftAt: "2026-10-06T09:00:00Z", previewAt: "2026-10-06T09:05:00Z", }; console.log(review(base)); console.log(review({ ...base, evidenceId: "" })); console.log(review({ ...base, previewAt: "2026-10-06T08:55:00Z" })); console.log(review({ ...base, owner: "" })); console.log(review({ ...base, recoveryReviewed: false })); READY_FOR_REVIEW HOLD HOLD HOLD HOLD Node.js v24.13.1에서 실행해 위 출력을 확인했습니다. 누락된 증거·담당자·복구 검토와 시각 역전은 HOLD 입니다. READY_FOR_REVIEW 는 사람의 검토에 넘길 조건입니다. 이번 실행은 합성 검토 기록 검사입니다. 실제 Drift 검사, Change Set 생성·실행과 AWS 요청은 수행하지 않았습니다. 실행 후에는 같은 동작을 확인합니다 담당자는 승인한 대상과 변경을 확인하고 운영 절차를 따릅니다. 완료 후 실제 속성, 연결된 서비스, 대표 요청을 확인합니다. 합성 주문 서비스에서는 새 주문 저장과 기존 주문 조회를 검사합니다. 완료 상태, 데이터 복원과 요청 성공을 기록합니다. 제한할 요청도 확인해 Hardening, 즉 보안 설정 보강의 목적을 검토합니다. 차이는 담당자에게 연결하고 다음 정의를 갱신합니다. 확인 문제와 해설 상위 Stack의 Drift 검사를 마쳤다면 Nested Stack은 어떻게 확인할까요? Change Set을 생성한 직후 어떤 단계가 이어지나요? 같은 변경에 Replacement가 추가되면 검토 양식에 무엇을 보충할까요? 해설 하위 Stack을 직접 검사하고 지원 대상과 결과를 연결합니다. 상위 검사의 확인 범위를 분명히 적습니다. 변경할 Resource와 속성, 교체와 서비스 영향을 검토합니다. 승인된 제안을 실행하고 실제 결과를 확인합니다. 복구 자료와 보존 조건, 복원 시험, 새 대상의 데이터와 연결 확인을 추가합니다. 예제는 recoveryReviewed 항목을 확인합니다. 복습과 다음 연결 오늘은 “현재 상태 → 미리보기 → 교체 영향 → 승인 → 검증”을 설명해 보세요. 하루 뒤에는 Nested Stack이 추가된 합성 양식에 확인 범위를 적습니다. 7일 뒤에는 긴급 조치의 설정을 다음 배포에 연결해 봅니다. 복습 제안 일정입니다. 공식 문서 확인일은 2026-10-06입니다. 다음 글 [AWS Hardening 14] Incident Drill에서 조사와 복구를 연습하기 에서는 증거, 승인된 격리, 접근 경로, 서비스 복구를 한 사건 기록으로 연결하겠습니다.
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
[AWS Hardening 13] CloudFormation 변경 전에 Drift와 영향 확인하기. 급한 문제를 해결하려고 서버 설정을 바꾼 상황을 가정해 보겠습니다. 서비스는 다시 동작합니다. 다음 배포 전에는 코드와 실제 값의 차이를 확인합니다. 이 차이가 변경 검토의 입력입니다. CloudFormation은 AWS Resource, 즉 서버와 저장소 같은 대상을 문서로 정의하고 배포하는 서비스입니다. 정의 문서는 Template이고 함께 관리하는 묶음은 Stack입니다. IaC는 구성을 코드로 관리하는 방식입니다. 앞선 조직 점검 편의 IaC를 변경 미리보기, 교체 영향, 실행 후 검증으로 연결하겠습니다. Drift는 기대한 값과 실제 값의 차이입니다 Drift는 Template과 Parameter에…
Open source