클라우드 보안. 이 용어 자체는 실제로 아무런 의미가 없습니다. "클라우드"를 구성하는 기본 인프라의 보안을 말씀하시는 건가요? 아니면 "클라우드"에서 컴퓨팅, 스토리지, 서비스를 프로비저닝하고 관리할 수 있는 명령 및 제어 API는 어떨까요?
당신이 마법처럼 자신의 실수로부터 당신을 보호해 줄 수 있는 그 능력에 대해 생각하지 못했을 거라는 걸 알기 때문입니다. Amazon S3 버킷의 기본 보안 정책을 의도적으로 변경하여 IP 주소를 가진 모든 사람이 버킷에 저장된 데이터에 액세스할 수 있도록 허용하는 경우를 말합니다.
그것이 터무니없는 생각이라고 생각한다면 옳습니다. 하지만 적절한 보안 역량을 갖춘 조직이 그런 일을 하지 않았다고 생각한다면 그것은 잘못된 생각입니다.
구체적인 사례로, 최근 특정 시스템 통합자가 Amazon S3에서 온갖 중요한 데이터를 공개해 놓아서 사용할 수 있게 했다는 사실이 밝혀졌습니다. 알다시피, 자격 증명이나 개인 키 같은 것들이죠. 해당 '오류'는 신속히 수정되었지만, S3에서 누구나 접근할 수 있는 상태에 도달하려면 운영자 측에서 조치를 취해야 한다는 사실은 여전히 남아 있습니다.
당신은 의식적으로 문을 열어야 합니다. Amazon S3는 기본적으로 액세스와 관련하여 엄격한 보안 제어 기능을 제공합니다. Amazon 문서에서:
기본적으로 모든 Amazon S3 리소스는 비공개입니다. 즉, 리소스 소유자만 리소스에 액세스할 수 있습니다.
따라서 올바른 IP 주소가 있는 사람이라면 누구나 버킷의 내용을 검색할 수 있는 상태로 만들려면 인간의 의식적인 행동이 필요합니다.
문제의 SI가 Amazon S3 보안을 해제하여 피해를 입은 첫 번째 기업은 아닙니다. 2017년 2월, 연구원 트로이 헌트는 사물인터넷 장난감인 클라우드 펫과 관련된 일련의 흥미로운 클라우드 보안 실패 사례를 자세히 설명했습니다 . 여기에는 "특정 승인이 필요 없는 Amazon S3 버킷"이 포함되었습니다. 7월에 우리는 3대 서비스 제공업체 중 하나가 잘못 구성된 Amazon S3를 통해 구독자 기록을 노출했다는 사실을 알게 되었습니다.
이 문제가 얼마나 만연한지 보여주기 위해 Rhino Security Labs는 Alexa 상위 10000개 사이트에서 Amazon S3를 테스트한 결과를 흥미로운 방식으로 보여주었습니다 . "68개의 고유 도메인에 속하는 목록 권한이 있는 107개 버킷(1.07%)이 발견되었습니다. 이 107개 버킷 중 61개(57%)는 이를 보는 모든 사람에게 공개 다운로드 권한이 있었습니다. 13개(12%)는 공개 업로드 권한을 가지고 있었고 8%는 세 가지 모두를 가지고 있었습니다."
공개 다운로드는 데이터가 도난당할 수 있다는 점에서 충분히 나쁜 방식입니다. 하지만 오픈 업로드도 가능한가요? 이는 직원들에게 피싱 이메일을 클릭하도록 권장하는 것과 같습니다.
클라우드는 당신을 자기 자신으로부터 보호할 수 없습니다. 보안 게이트, 검사 또는 감독이 부족 하든, 클라우드 저장소에 대한 권한을 그냥 열어두고 누구도 찾지 못하기를 바랄 수는 없습니다. 그것은 CCTV를 설치하고 외부에 Telnet 접속을 열어두는 것과 같습니다.
어, 그렇군요?
문제는 이겁니다. 앱과 데이터의 보안은 이를 보호하는 정책 및 절차에 따라 결정됩니다. S3와 같은 클라우드 스토리지가 "오픈" 액세스를 허용하는 데에는 정당한 이유가 있습니다. 하지만 회사 방화벽의 포트와 마찬가지로, 정말 좋은 이유가 없다면 포트를 완전히 열어두어서는 안 됩니다.
앱을 켜거나 URL을 공유하기 전에 "클라우드 보안"을 검토하도록 요구하는 정책을 아직 제정하지 않았다면 그렇게 해야 합니다. 지금 바로. 뭐, 읽는 걸 멈추고 가서 작업을 시작해 보세요.
자신이 가장 큰 적이 되지 마십시오. 정책과 절차를 확인하고, 클라우드에 저장하는 데이터의 중요성과 지정된 용도에 맞게 보안을 조정해야 합니다.
S3 구성 오류가 뉴스의 헤드라인을 장식하는 것을 방지할 수 있는 사람은 바로 여러분뿐입니다.
Amazon S3 버킷을 잠그는 데 도움이 필요한 경우 Amazon은 도움이 되는 설명서 뿐만 아니라 도구도 친절하게 제공합니다.