[reinvent 2024] Amazon S3에 대한 보안패턴에 대한 심화

들어가며

AWS최초의 서비스는 S3라는 것을 기억하십니까? 2006년 3월 14일에 출시한 S3는 전에 없던 객체스토리지라는 개념을 최초로 상용화한 스토리지 서비스였습니다. 이후 이 개념은 다른 스토리지서비스에 영향을 끼치며,  컴퓨팅생태계를 지배하는 유수의 기업들(Google, Microsoft, OpenStack 등)이 앞다퉈 서비스를 출시하기도 했습니다.

Google Cloud Storage (2010년), Microsoft Azure Blob Storage (2010년), OpenStack Swift (2010년, 오픈소스)가 그것입니다. 아마 다뤄보지 않으셨다면, 이들 간의 차이점을 경험해보시는 것도 좋겠습니다.

저는 OpenStack의 Swift를 통해 객체스토리지 개념을 접했는데, 당시 크게 당황했던 기억이 있습니다. 기존에 제가 경험한 블록스토리지, 파일시스템스토리지와는 너무나도 다른 경험을 주었기 때문입니다.

블록과 파일시스템기반 스토리지만 존재하던 On-premise시절을 지나 객체스토리지의 시대로 접어들며 우리는 더 Cloud-Native한 환경으로 변모하고 있다고 생각합니다.

강물이 바다로 모이듯, 모든 데이터는 S3 로 모이는데 우리는 S3에 대해 얼마나 잘 알고있는지 반문해 봅니다.

마치 S3는 공기와 같아서 쉽게 가져다 쓸수있지만, 더 복잡하고 높은 보안을 요구하게 되면, 이런 논의를 했었음을 상기하고 담담하게 받아들이고 싶습니다.

믿을 수 없을 정도로 수많은 보안 요구사항을 수용하고 있는 S3의 정책과, 이 S3의 아키텍처에 집중하여 더 제대로 인식하는 계기가 되었으면 합니다.

정책을 위한 Mental모델 (우리가 AWS의 리소스정책을 이해하는 방식)

1번째 패턴에서 멘탈모델이란 말이 나오는데 우리가 세상과 상호작용할때 사용하는 인지적 구조를 의미하며, 심리학에서 나온 개념이니 더 깊이 들어가진 않겠습니다.

저같은 경우 ’Principal이 Resource에 Action하는걸 Effect한다’고 정책구성을 원활히 하기위해 쉬운 말을 만들어보는데, 이러한 인지구조가 권한을 기술하는데 자연스럽다고 생각합니다. 

주체(Principal)가 자원(Resource)에 무언가의 행위(Action)를 하는 것에 대해 허용을 할지, 거부를 할지에 대한 영향 또는 의사결정(Effect)을 정책으로 서술하면, 권한에 대한 머릿속의 생각이 정책을 표현하는 문장으로 기술하는 것과 실제 그렇게 쓰여진 정책이 그렇게 동작하는 것이 만나는 경험은 확신으로 이어집니다. 그래서, S3의 리소스정책도 PEAR(Principal, Effect, Action, Resource의 약자) 를 콕 찍어서 고민하는 편입니다.

강연자인 Bryant는 정책을 작성할때 2가지를 꼭 생각을 해야한다고 말하는데, 하나는 boundary vs. path로 identity정책을 제한하는 permission boundary와  S3자원을 의미하는 data path이며,  구체적으로는 S3버킷, S3버킷 내 객체(object)를 의미합니다.

Boundary는 Identity에 부여되는 권한을 제한하는 권한경계를 의미하는데, Identity의 권한이 AmazonS3FullAccess더라도, Boundary가 AmazonS3ReadOnlyAccess로 제한된다면 이 둘의 교집합인 AmazonS3ReadOnlyAccess의 권한만 부여되는 결과를 볼 수 있습니다.

이 Boundary는 전역적인 효과가 있으므로, 모든 리소스에 영향을 끼칩니다.  또한, Boundary에 일부 서비스의 권한을 기술하게되면, 기술하지않은 영역에 대해 강력한 제한을 가하게 되므로 적용 전에 충분한 고려가 필요합니다.

예를 들어, Boudary에 AmazonS3ReadOnlyAccess권한만 기술된다면, Identity의 권한이 AdministratorAccess일지라도 그 교집합인 AmazonS3ReadOnlyAccess권한만이 유효하게 됩니다.

따라서, 시스템을 구축하는 시점에는 Boundary의 사용이 그다지 고려되지않습니다.  구축 완료 후 ControlTower나 Organization서비스를 활용하여 멀티계정의 일괄적인 보안정책의 적용시에 SCP(Service Control Policy)방식으로 적용하는 것이 일반적입니다.

결론적으로는, Boundary는 전역적이며, 제한을 강제하고, 제도준수와 보안에 촛점이 맞춰져 있습니다.

이에 반해 path는 버킷, 버킷 내 object를 표현하는 구체적인 리소스를 나타내며, 애플리케이션이 접근할 구체적인 대상, 혹은 폴더인 경우 폴더 내의 모든 객체를 나타내므로 데이터의 활용에 초점이 맞춰져 있습니다.

또 하나는 Principal vs. Resource로서 ‘자원에 접근하는 주체(Principal)’와 ‘주체의 액션에 대응하는 자원(Resource)’에 대한 인지가 필요한데, 이 건에 대해서는 저도 강력히 동의합니다.

권한의 기술이 필요한 시점에 권한이 정의되지않은 상황을 생각해 보세요.  권한을 백지에서 정의하는 시점에 모든 권한은 ‘접근하는 자’와 ‘접근대상’이 무엇인지로부터 생각을 시작할 수 있습니다.

최소권한의 법칙 (보안에서 항상 강조되는 것들)

보안에서 항상 강조되는 최소권한의 법칙이 있고, AWS에서도 예외는 아닙니다. 우리는 SA로서 작업을 위해 제공되던 AWS의 IAM-user를 보안이 강화된 고객을 통해서는 IAM-role을 통해 접근하도록 통제받는 경우가 있습니다.

강연자인 Bryant는 S3의 접근제어를 위해 IAM-user를 사용하는 것보다 필요할때마다 권한을 부여하는 Token Vending Machine개념을 주장합니다.   더 짧은 시간, 더 적은 권한을 필요할 때만 부여하고 할당하는 개념입니다.

특이할만한 사항은 클라이언트인 application과 서버역할인 S3버킷 간에 리소스접근이 발생하는 것이 아니라, 클라이언트는 서버로부터 임시 보안 자격 증명만을 제공받아 사용자에게 전달하고, 사용자가 임시 보안 자격 증명을 가지게하여 사용자로 하여금 해당하는 자원에 접근하게하는 방식입니다.

그 예시로는 Pre-signed URL방식, On-demand request signer 방식과 S3 Access Grants를 들었습니다.

Application에서 접근한 이 관점은 서버가 최종사용자에게 최종결과물인 자원까지 전달하는 전통적인 방식과 달라서, 다소 낯선 사용방식이었습니다.  향후에 한번 더 이 세션을 복기해 보고 싶네요.

권한문제해결을 위한 과감함 (설정 변경을 감지하고 되돌리기)

Bryant는 권한수정의 영원한 걸림돌인 ‘기존 사용자의 반발’을 회피하기 위해 과감해질 필요가 있다고 합니다.

운영중인 서비스에 새롭거나 더 강화된 보안을 적용하는 것은 매우 어렵고, 성과를 이루기 어려운 일이지만, AWS의 수많은 서비스를 연계하면 event기반 아키텍처로 이를 극복할 수 있습니다.

스크린샷의 예시처럼 특정리소스의 Block Public Access설정변경을 SecurityHub에 전달하고, SecurityHub는 Findings를 확인하고, 이벤트를 Trigger하여 Lambda가 동작하게 하면 설정변경을 되돌릴 수 있는 아키텍처입니다.

물론, 이 아키텍처는 한 예시일 뿐이며 사용된 서비스와 설정을 더 면밀히 고려해야할 것입니다.

정리

최종적으로 아래와 같이 요약할 수 있겠습니다.

• 리소스 정책 구성시에는 boundary를 설정할 것인지, data path를 활성화할 것인지 사이에 적절한 정책 유형을 사용할 것
• IAM 사용에 얽매이지않고 AWS접근 제어를 확장하기 위해  임시자격 자동발급(VTM)패턴을 활용할 것
• 의도치않은 잘못된 구성의 효율적인 교정(correct)을 위해 서버리스 모니터링을 사용할 것

결론

S3를 사용하며 부지불식간에 아는대로 사용하는 자신을 돌아보게 됩니다. S3는 리소스의 상징일 뿐이며, 모든 리소스는 그의 방식에 맞는 리소스정책이 있고, 우리는 그것을 최대한 사용해야합니다. 그리고, 코드개발자에 적절한 가이드와 더 좋은 보안방안을 제공하는 것도 필요할 것입니다.

S3는 객체스토리지로서 버킷뿐만이 아니라, 객체하나하나에 대한 세세한 조절이 가능합니다. 이는 AWS 콘솔로만 성취하기는 어려운 부분이 있으며, 코드작성을 통한 접근이 소개된 아키텍처의 이해에 효과적으로 보입니다. 

그래서, 최근 2년 동안에 저는 Shell Script보다 Python Script를 작성하는데 시간을 더 씁니다. 더 나아가서 Python을 통해 SDK(boto3)를 통한 API 접근을 대한 사고의 확장을 경험했습니다. 이 경험이 개인의 노력으로 달성가능할지 모르겠지만, 확실한건 어제보다 나아지는 오늘이 있다는 겁니다. SA로서 보안과 개발에 관심을 놓을 수 없는 이유입니다.