KMS의 중요한 심화
주제인 키 교체에 대해 이야기하겠습니다
AWS 관리 CMK가 아니라 고객
관리 CMK에 대해 자동 키 교체를 활성화할 수 있습니다
자동 키 교체를 활성화하면
1년마다 발생합니다
1년이 지나면 키는 바뀌지만
이전 키는 계속 활성화가 유지됩니다
따라서 이전 데이터도 해독할 수 있습니다
새 키도 같은 CMK ID를 가질 것입니다
다시 말하자면 보조 키의
보조 머티리얼만 바뀐다는 의미입니다
예를 들어보겠습니다
여기 보조 키와 CMK ID가 있습니다
1년마다 자동 교체가
일어나는데 기간은
바꿀 수 없습니다 1년마다 해야 합니다
그럼 보조 키가 바뀝니다
키의 머티리얼이 바뀐다는 의미입니다
그러나 CMK ID는 동일하게 유지됩니다
이전 보조 키는 저장되기 때문에 여전히 이전
데이터를 해독할 수 있습니다
이것이 자동 키 교체입니다
그러나 수동으로 키를 돌릴 수도 있습니다
예를 들어 키를 90일마다
또는 180일 마다 교체하려면
새 키는 다른 CMK ID를 갖게 됩니다
수동으로 생성하기 때문입니다
이전 키를 활성화 시켜서 이전 데이터를 해독할
수 있도록 하는 것입니다 그렇지 않으면
이전 데이터에 대한 접근을 잃게 됩니다
이 경우에는 데이터를 암호화하고 해독할
때 alias(별칭)을 쓰는 것이 좋습니다 별칭을 사용하면
앱의 키가 교체되는 것을 숨길 수 있습니다
도표로 보여드리겠습니다
따라서 비대칭 CMK처럼 자동 교체가
불가능한 CMK를 교체하기 위해
적합한 해결책입니다
여기 예제가 있습니다
클라이언트는 현재 MyCustomKey를 별칭으로 칭하고
보조 키와 CMK ID가 있습니다
그런 다음 새 키를 생성해
수동으로 키를 교체 시킵니다 별칭도 바꿉니다
이제 새 CMK ID가 생길 것입니다
이전 보조 키는 여전히 여기 있지만
여러분의 클라이언트는
새 별칭이 새 머티리얼을 가리킬 거라고
생각하게 됩니다 수동 키도 교체됐습니다
별칭을 업데이트하려면 어떻게 해야 할까요?
별칭을 업데이트해 애플리케이션에
변화를 숨깁니다 여러분의
애플리케이션은 API 측면에서
키 별칭 MyAppKey와만 상호 작용합니다
그리고 키 별칭의 예전 키는 교체 전에
있던 건데 교체 후에 새 키를 생성하고
UpdateAlias API
코드를 발급 받습니다
이 업데이트 별칭은 새 키를
가리키게 됩니다
따라서 애플리케이션 관점에서는
변화가 감지되지 않습니다
투명해질 것입니다
시험에서 기억해야 할 것은
자동 키 교체를 원할 경우 기간은 1년이지만
수동 키 교체를
원할 경우 요구 사항에 따라
90일 또는 180일로 할 수 있다는
것입니다다
추가 정보를 드린 건 실제로
어떻게 진행되는지 보여드리기 위해서입니다
그러나 제가 알기로 이 시험에 세부 사항에 대한
문제가 나오지 않을 것입니다
이번 강의는 여기까지입니다
마음에 드셨으면 좋겠습니다
다음 강의에서 뵙겠습니다