CloudTrail, 기본으로 남지 않는 기록

AWS 콘솔에서 CloudTrail을 열고 ‘이벤트 기록’⁠을 누르면, 따로 설정한 적이 없는데도 최근 활동이 줄줄이 나온다.
누가 언제 인스턴스를 만들었는지, 누가 콘솔에 로그인했는지까지 보인다.

그래서 계정에서 일어나는 일이 다 남고 있다고 여기기 쉽다.
그런데 이 화면에는 빠진 것이 꽤 있다.

무엇이 기본으로 남고 무엇이 남지 않는지는 사고가 나기 전에 알아 둬야 한다.
남지 않은 기록은 나중에 만들 수 없다.

CloudTrail은 API 요청을 기록한다

AWS에서 하는 일은 결국 API 요청이다.
API는 프로그램이 서비스에 일을 시킬 때 쓰는 정해진 요청 형식인데, 콘솔에서 버튼을 눌러도 뒤에서는 같은 요청이 나간다.

CloudTrail⁠은 이 요청 하나하나를 이벤트로 남기는 서비스다.
사용자나 역할, AWS 서비스가 한 작업이 이벤트가 되고, 누가 어떤 자원에 언제 무엇을 했는지가 담긴다.
여기서 사용자와 역할은 AWS의 권한 관리 서비스인 IAM에 만든 신원이다.

이벤트를 하나 열어 보면 항목 이름이 영어로 나온다.
userIdentity는 요청한 사용자나 역할, eventName은 요청한 작업, sourceIPAddress는 요청이 온 IP 주소, eventTime은 요청이 끝난 시각이다.

이벤트의 원본 기록에서 eventTime은 협정 세계시(UTC)⁠로 적혀 있다.
한국 시간으로 읽으려면 9시간을 더한다.

이벤트 기록 화면은 계정을 만들 때부터 켜져 있고, 별도 요금 없이 최근 90일치를 보여 준다.
이벤트는 그 일이 일어난 리전에 기록된다.
콘솔에서 고른 리전의 활동만 보이므로, 다른 리전에서 벌어진 일은 리전을 바꿔서 봐야 한다.

설정을 다룬 기록과 데이터를 읽은 기록

CloudTrail의 이벤트는 크게 두 갈래다.
하나는 자원 자체를 만들고 지우고 설정을 바꾸거나, 자원이 어떻게 설정돼 있는지 조회하는 작업이다.
AWS는 이것을 관리 이벤트라고 부르고, 제어 평면(control plane)⁠의 작업이라고도 한다.

IAM 역할에 정책을 붙이거나 서브넷을 만드는 일, 보안 그룹 목록을 조회하는 일이 모두 관리 이벤트다.
누가 콘솔에 로그인했는지도 여기에 함께 기록된다.

다른 하나는 자원 안의 데이터를 읽고 쓰는 작업이다.
S3 버킷에서 파일을 내려받거나 올리는 요청, Lambda 함수를 호출하는 요청이 여기에 들어간다.
이쪽은 데이터 이벤트, 또는 데이터 평면(data plane)⁠의 작업이라고 부른다.

CloudTrail은 기본으로 관리 이벤트만 남기고, 데이터 이벤트는 따로 설정해야 남긴다.
이벤트 기록 화면은 데이터 이벤트를 아예 보여 주지 않는다.

이유는 양이다.
데이터 이벤트는 대개 대량으로 일어나고, 기록하면 별도 요금이 붙는다.
설정은 가끔 바뀌지만, S3 요청은 사용자가 사진을 올리고 내려받을 때마다 하나씩 생긴다.

기록은 일이 일어난 순간에만 남는다

추적(trail)⁠은 CloudTrail 이벤트를 S3 버킷 같은 곳에 계속 쌓아 두도록 따로 만드는 설정이다.
추적에는 어떤 이벤트를 남길지 정하는 조건인 이벤트 선택기가 붙는다.

CloudTrail은 이벤트가 일어날 때 각 추적의 선택기와 대조해서, 맞으면 기록하고 맞지 않으면 기록하지 않는다.
지나간 이벤트를 다시 대조하는 단계는 없다.

그래서 데이터 이벤트 기록을 오늘 켜면, 오늘부터 일어나는 읽기와 쓰기만 남는다.
어제 누군가 파일을 내려받았다면 그 사실은 이 추적 어디에도 없다.
같은 파일을 기록을 켜기 전에 한 번, 켠 뒤에 한 번 읽으면 두 번째 읽기만 남는다.

파일을 한 번 읽은 뒤 데이터 이벤트 기록을 켜고, 같은 파일을 다시 읽는 예시다.

첫 파일 읽기

이미 발생

trail 기록

없음

데이터 이벤트 기록 꺼짐

선택한 S3 데이터 이벤트 기록을 켜기 전의 읽기는 이 trail에 없고, 켠 뒤 읽기부터 남는다.

파일은 읽혔지만 이 trail에는 데이터 이벤트가 기록되지 않았다.

기록을 켰다. 켜기 전에 읽은 사실이 새로 나타나지는 않는다.

같은 파일을 다시 읽은 이번 사건부터 기록이 남는다. 기록 없음은 사건 없음과 다르다.

trail의 선택된 데이터 이벤트 예시다. 기본 Event history의 관리 이벤트와는 별개이며, 실제 로그 전달 시간은 생략한다.

데이터 이벤트는 범위도 골라서 켠다.
버킷을 지정할 수 있고, 내려받기 같은 읽기와 올리기 같은 쓰기를 따로 고를 수 있다.
쓰기만 골라 둔 버킷에서는 누가 파일을 내려받았는지 남지 않는다.

접근 키가 새어 나갔다면

접근 키(access key)⁠는 프로그램이 AWS API를 부를 때 신원을 증명하는 데 쓰는 자격 증명이다.
이 키가 외부에 노출됐다면, 관리 이벤트 덕분에 그 키로 언제 어떤 사용자를 만들었는지, 어떤 설정을 바꿨는지는 확인할 수 있다.

그런데 그 키로 S3에서 어떤 파일을 내려받았는지는 데이터 이벤트다.
그 버킷에 읽기 기록을 켜 두지 않았다면 CloudTrail에는 답이 없다.

이럴 때 기록이 없다는 사실만으로 아무것도 가져가지 않았다고 볼 수는 없다.
그렇다고 전부 가져갔다고 단정할 수도 없다.
애플리케이션 로그 같은 다른 증거를 모아, 확인된 사실과 알 수 없는 범위를 나눠서 정리한다.

S3 서버 접근 로그도 그런 증거가 될 수 있다.
다만 이것도 미리 켜 둬야 남고, 전달이 최선 노력(best-effort) 방식이라 일부 요청의 기록이 빠질 수 있다.

90일보다 오래된 기록은

보관 기간도 따로 봐야 한다.
이벤트 기록 화면은 90일이 지난 이벤트를 보여 주지 않는다.
침입은 한참 뒤에야 발견되기도 해서, 알아챘을 때는 처음 흔적이 이미 90일 밖에 있을 수 있다.

오래 남기려면 추적이나 CloudTrail Lake의 이벤트 데이터 저장소를 만들어야 한다.
추적을 만들면 진행 중인 관리 이벤트 한 벌을 CloudTrail 요금 없이 S3 버킷으로 보낼 수 있고, S3 저장 요금만 든다.

AWS는 모든 리전의 활동을 담는 다중 리전 추적을 권하고, 콘솔에서 만드는 추적은 모두 다중 리전이다.
앞에서 본 리전별 화면의 빈틈도 여기서 메워진다.

기록	기본 상태	미리 해 두지 않으면
설정을 다룬 기록	이벤트 기록 화면에 리전별로 90일	90일이 지난 흔적을 거슬러 보지 못한다
데이터를 읽고 쓴 기록	남지 않는다	무엇이 실제로 나갔는지 특정하지 못한다
추적으로 S3에 쌓은 기록	만들지 않으면 없다	여러 리전의 기록을 한곳에서 오래 보지 못한다

계정을 만들고 나서 해 둘 일

먼저 다중 리전 추적을 하나 만들어 관리 이벤트를 S3 버킷에 쌓아 둔다.
관리 이벤트 한 벌은 CloudTrail 요금 없이 보낼 수 있으니 미룰 이유가 적다.

데이터 이벤트는 답해야 할 질문을 먼저 정하고 켠다.
고객이 올린 파일이나 개인정보가 든 버킷이라면 ‘누가 이 파일을 읽었나’⁠에 답해야 할 수 있으니 읽기 기록을 켜 두는 쪽이 맞다.
모든 버킷에 켜면 요청이 많은 버킷에서 요금이 크게 늘 수 있다.

기록을 남기는 설정 자체도 지켜야 한다.
권한이 넓은 사용자가 추적을 끄지 못하게 조직 정책으로 막는 방법은 SCP 글에서 다룬다.

데이터 이벤트를 켜지 않은 버킷에서는 누가 어떤 파일을 읽었는지 나중에 확인할 방법이 없다.
어느 버킷을 켜고 어느 버킷을 뺐는지 적어 두면, 사고가 났을 때 조사할 수 있는 범위가 바로 보인다.