월요일 오전, 기업 보안팀 회의실.
팀장이 AI 챗봇 도입을 검토하지만, 인사팀의 급여 명세서가 전 직원에게 노출될까 봐 걱정하며 고개를 젓는다.
이런 보안 우려는 Amazon Quick의 새로운 기능으로 해결된다.
Amazon Quick의 S3 문서 단위 ACL 도입
Amazon Quick(AI 기반 검색 및 채팅 도구)는 Amazon S3(클라우드 저장소) 지식 베이스를 위한 ACL(접근 제어 목록, 누가 어떤 파일에 접근할 수 있는지 정의한 리스트) 기능을 도입했다. 이 기능은 문서나 폴더 단위로 세밀하게 권한을 설정할 수 있게 해준다. 사용자가 질문을 던지면 시스템이 사용자의 신원을 확인하고, 권한이 허용된 콘텐츠만 검색 결과로 보여준다.
설정 방식은 두 가지로 나뉜다. 전체 권한을 한 번에 관리하는 글로벌 ACL 방식과 개별 문서의 메타데이터 파일에 권한을 적어두는 방식이 있다. 글로벌 방식은 권한이 바뀔 때마다 해당 경로의 모든 데이터를 다시 읽어 들이는 전체 재인덱싱(데이터를 검색 가능하게 다시 정리하는 작업)이 필요하다. 반면 메타데이터 방식은 변경된 문서만 다시 처리하면 된다.
기본 원칙은 명시적으로 허용되지 않은 모든 접근을 차단하는 것이다. 예를 들어 S3 버킷에 재무, 법무, 정책 폴더가 있을 때 ACL 파일에 재무와 정책 폴더만 허용했다면, 법무 폴더는 아무런 거부 규칙이 없어도 자동으로 차단된다. 만약 한 사용자에게 허용과 거부 권한이 동시에 부여되었다면, 거부 권한이 항상 우선한다.
기존 권한 관리와 달라진 지점
예전에는 지식 베이스 전체에 대해 권한을 주는 뭉툭한 방식이었다. 비유하자면 도서관 전체 출입증을 주는 것과 같아서, 일단 들어가면 모든 책을 볼 수 있었다. 이제는 개별 사물함 열쇠를 주는 방식으로 바뀌었다. 사용자는 자신이 가진 열쇠로 열 수 있는 서랍의 문서만 읽을 수 있다.
운영 효율 면에서도 차이가 생긴다. 이전에는 작은 권한 수정 하나에도 전체 시스템을 다시 훑어야 하는 부담이 컸다. 이제는 메타데이터 방식을 통해 필요한 부분만 콕 집어 업데이트할 수 있어 리소스 낭비를 줄였다.
보안 담당자가 체감하는 가장 큰 변화는 권한의 우선순위 제어다. 팀 전체에 넓은 허용 범위를 설정한 뒤, 특정 민감 문서에 대해서만 거부 규칙을 덧씌우는 정교한 설계가 가능해졌다. 이를 통해 조직 구조를 완전히 바꾸지 않고도 빠르게 보안 정책을 적용할 수 있다.
하지만 문서 접근 권한만으로는 부족한 틈새가 있다. ACL은 이미 만들어진 지식 베이스 내의 문서 접근을 막을 뿐, 누군가 S3 버킷을 이용해 새로운 지식 베이스를 만드는 것 자체는 막지 못한다. 권한이 없는 사용자가 ACL 설정을 끄고 새 지식 베이스를 만들면 보안망이 무력화된다.
이 구멍을 막기 위해 IAM(사용자 권한 관리 도구) 정책을 함께 사용한다. 특정 S3 버킷을 이용해 지식 베이스를 생성할 수 있는 사용자를 관리자 그룹으로 제한하는 방식이다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1",
"arn:aws:s3:::amzn-s3-demo-bucket2"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
}
]
}
관리자는 위와 같은 정책을 생성해 Quick 사용자나 그룹에 할당하면 된다. 이렇게 하면 허가받지 않은 사용자는 제한된 S3 버킷으로 지식 베이스를 생성할 수 없게 된다.
AI의 편리함은 이제 '누가 무엇을 볼 수 있는가'라는 정교한 통제권 위에서 완성된다.
