CloudTrail, 기본으로 남지 않는 기록
설정을 바꾼 기록과 파일을 읽은 기록은 따로 남아요. CloudTrail의 관리·데이터 이벤트, 보관 범위가 답할 수 있는 질문을 알아봐요.
이 글의 목차무엇을 바꿨나와 무엇을 읽었나4
건물에 폐쇄회로 카메라가 달려 있다는 사실과 어젯밤 일이 녹화돼 있다는 사실은 달라요. 카메라가 로비만 찍고 있었다면 창고에서 무슨 일이 있었는지는 어디에도 없어요. 사건이 난 다음에는 각도를 바꿀 수 없어요.
AWS의 감사 기록도 그래요. 계정을 만들면 활동 기록이 남기 시작하지만, 모든 활동이 같은 방식으로 남는 것은 아니에요. 이 구분을 모르면 사고가 났을 때 가장 알고 싶은 것만 없는 상황이 생겨요.
무엇을 바꿨나와 무엇을 읽었나
기록은 크게 두 갈래로 나뉘어요. 하나는 자원을 만들고 지우고 설정을 바꾸는 활동이에요. 역할을 새로 만들거나 보안 그룹 규칙을 열거나 인스턴스를 지우는 일이 여기 속해요. AWS 문서는 이것을 관리 이벤트, 다른 말로 제어 평면의 활동이라고 불러요.
다른 하나는 그 자원 안의 데이터를 실제로 읽고 쓰는 활동이에요. 저장소의 특정 파일을 내려받거나, 테이블의 행을 읽거나, 함수를 호출하는 일이에요. 이쪽을 데이터 이벤트라고 불러요.
핵심은 다음 한 줄이에요. AWS 문서는 관리 이벤트와 달리 데이터 이벤트가 기본으로 기록되지 않는다고 명시하고, 남기려면 따로 설정하라고 적어요. 그럴 만한 이유가 있어요. 같은 문서군의 설정 안내는 추적과 저장소가 기본적으로 데이터 이벤트를 남기지 않는다는 것을 다시 확인하면서, 데이터 이벤트가 대개 대량 활동이고 별도 요금이 붙는다고 적어 둬요. 데이터 접근은 설정 변경보다 압도적으로 자주 일어나서, 전부 남기면 양과 비용이 다른 차원이 돼요.
파일을 읽은 뒤 데이터 이벤트 기록을 켜고, 같은 파일을 다시 읽어 보세요.
첫 파일 읽기
이미 발생trail 기록
없음데이터 이벤트 기록 꺼짐
첫 파일 읽기
여전히 기록 없음새 기록 설정
이제부터 켜짐켜기 전 읽기
기록 없음켠 뒤 읽기
기록 남음선택한 S3 데이터 이벤트 기록을 켜기 전의 읽기는 이 trail에 없고, 켠 뒤 읽기부터 남아요.
파일은 읽혔지만 이 trail에는 데이터 이벤트가 기록되지 않았어요.
trail의 선택된 데이터 이벤트 예시예요. 기본 Event history의 관리 이벤트와는 별개이며, 실제 로그 전달 시간은 생략해요.
사고 조사에서 없는 쪽
이 기본값이 만드는 상황을 그려 보면 문제가 분명해져요. 자격 증명이 유출됐다고 해 볼게요. 누가 언제 그 역할을 맡았고 어떤 설정을 바꿨는지는 남아 있어요. 그런데 정작 가장 알고 싶은 것, 그러니까 그 자격 증명으로 어떤 파일을 실제로 가져갔는지는 따로 켜 두지 않았다면 어디에도 없어요.
기록이 없으면 실제로 무엇을 가져갔는지 입증하기 어려워요. 그렇다고 그 사실만으로 전부 유출됐다고 확정할 수도 없어요. 애플리케이션 로그와 저장소 기록 등 다른 증거를 함께 보고, 확인된 사실과 아직 알 수 없는 범위를 나눠야 해요. 감사 기록은 그 불확실성을 줄이는 재료예요.
그렇다고 전부 켜는 것이 답도 아니에요. 앞 글에서 관측을 이야기하며 적은 것과 같은 구조예요. 무엇을 남길지는 저장 비용의 문제처럼 보이지만 실제로는 나중에 던질 수 있는 질문의 목록을 미리 정하는 일이에요. 그래서 민감한 데이터를 담은 자리부터 골라서 켜는 쪽이 현실적이에요.
기록이 있다는 것과 볼 수 있다는 것
한 겹이 더 있어요. 콘솔에서 최근 활동을 바로 되짚어 볼 수 있는 화면과, 기록을 저장소에 계속 쌓아 두도록 따로 만드는 설정은 다른 물건이에요. AWS 문서는 앞의 것이 계정을 만들면 바로 쓸 수 있고 별도 요금도 없지만 지난 90일치 관리 이벤트로 한정된다고 적고, 같은 자리에서 이 화면이 데이터 이벤트를 아예 보여 주지 않으니 계속 남기려면 저장소나 추적을 따로 만들라고 안내해요. 사고는 대개 벌어지고 한참 뒤에 발견되므로, 발견했을 때 이미 그 기간을 넘긴 경우가 드물지 않아요.
| 무엇 | 기본 상태 | 없을 때 못 하는 것 |
|---|---|---|
| 설정을 바꾼 기록 | 남는다 | — |
| 데이터를 읽고 쓴 기록 | 따로 켜야 남는다 | 무엇이 실제로 나갔는지 특정하기 |
| 오래 보관하는 설정 | 따로 만들어야 한다 | 한참 뒤에 발견한 사고를 거슬러 보기 |
세 줄 모두 사고가 난 뒤에는 소급해서 만들 수 없다는 공통점이 있어요. 보험과 성격이 같아서, 필요해진 시점에는 이미 늦어요.
저는 무엇을 켜 두었나
제가 만드는 앱은 다루는 데이터가 많지 않아 이 문제를 큰 규모로 겪지는 않았어요. 다만 계정을 만들고 한동안 아무것도 손대지 않았다가, 앞 글에서 배포 자격 증명을 정리하면서 함께 들여다봤어요.
그때 확인한 것은 기록이 켜져 있느냐가 아니라 어떤 질문에 답할 수 있느냐였어요. 누가 언제 역할을 맡았는지는 답할 수 있었고, 어떤 파일을 가져갔는지는 답할 수 없었어요. 후자를 답할 수 있게 만드는 데 드는 비용과 그 답이 필요해질 확률을 견줘 보고, 민감한 자리에만 켜기로 정했어요.
감사 기록은 평소에 아무 값도 하지 않다가 딱 한 번 값을 해요. 그 한 번이 언제일지 모르기 때문에, 지금 무엇을 답할 수 없는지 한 번쯤 세어 볼 이유가 있었어요.