본문으로 건너뛰기
Menu
AIMarketingNewsToolsAbout

클라우드·보안 운영

AWS CDK를 패치해도 남는 권한…Redshift 운영자가 따로 볼 것은

발행일:

AWS CDK Redshift alpha의 보안 업데이트는 이미 부여된 PUBLIC 권한을 회수하지 않습니다. 영향 버전과 적용 조건, 업데이트 뒤 따로 확인할 데이터베이스 권한을 정리합니다.

AWS CDK 주제로 데이터베이스와 방패, 남아 있는 접근 열쇠와 승인된 보라색 VECTO를 배치한 AI 생성 3D 개념 이미지. 실제 제품 화면이 아닙니다.

보안 업데이트를 끝냈다고 데이터베이스에 남아 있는 권한까지 원래대로 돌아가는 것은 아닙니다. AWS는 10월 26일 공개한 CDK Redshift alpha 보안 공지(CVE-2026-115418)에서 패키지 업데이트와 기존 테이블의 PUBLIC 권한 검토를 함께 권고했습니다. 이미 부여된 권한은 업그레이드만으로 제거되지 않기 때문입니다. AWS 공식 공지와 공식 GitHub 보안 권고에 따른 내용입니다.

Redshift 전체가 아니라, 배포를 만드는 alpha 모듈 문제입니다

대상은 AWS CDK의 실험적 모듈인 @aws-cdk/aws-redshift-alpha입니다. 코드로 Redshift 사용자·테이블·권한을 관리하는 도구로, 영향 버전은 2.274.0-alpha.0 미만, 수정 버전은 2.274.0-alpha.0입니다. Redshift 서비스를 사용한다는 이유만으로 모든 환경이 이번 취약점에 해당하는 것은 아닙니다.

문제는 사용자 이름·주석·비밀번호 등의 설정값이 배포 시 실행되는 SQL에 반영되는 과정에서 발생합니다. 공격자가 해당 CDK 애플리케이션의 설정값에 영향을 줄 수 있으면, 의도와 다른 SQL이 Redshift 슈퍼유저 권한으로 실행될 수 있습니다. AWS는 그 결과에 클러스터의 모든 사용자에게 접근 권한을 주는 경우도 포함된다고 설명했습니다. 단순히 외부에서 접속할 수 있다는 것만으로 성립하는 조건은 아닙니다. 공식 권고의 영향 범위

AWS CDK Redshift alpha 공식 README의 Granting Privileges 항목과 Table.grant 예제, 여러 CDK 애플리케이션의 권한 관리 충돌 주의 문구.

AWS CDK v2.274.0 README 실제 화면입니다. 테이블 권한 부여 기능과 여러 CDK 앱에서 같은 권한을 관리할 때의 주의점을 보여줍니다. 보안 공지나 공격 사례 화면은 아닙니다. 공식 원문, 2026년 10월 27일 확인. Amazon.com, Inc. or its affiliates, Apache 2.0 · NOTICE.

PUBLIC은 인터넷 공개라는 뜻이 아닙니다

이 공지에서 PUBLIC은 데이터베이스의 모든 사용자를 포함하는 그룹을 뜻합니다. 나중에 만들어지는 사용자도 포함됩니다. 웹페이지를 검색에 공개하거나 인터넷 누구에게나 익명 접근을 허용한다는 의미와는 다릅니다. Redshift의 GRANT 설명

그래도 운영상 의미는 큽니다. 예를 들어 특정 분석 담당자만 읽어야 하는 테이블을 여러 업무 계정이 함께 쓰는 환경을 가정해보겠습니다. 그 테이블에 불필요한 PUBLIC 권한이 남았다면, 패키지를 수정했더라도 의도한 계정 구분이 회복됐다고 볼 수 없습니다. 이는 이해를 위한 가상 예시이며 실제 고객의 피해 사례는 아닙니다.

이번 공지를 운영 관점에서 읽을 때 핵심은 두 가지 상태를 나눠 보는 것입니다. 앞으로 잘못된 명령이 만들어지지 않도록 도구를 고치는 일과, 이미 데이터베이스에 반영된 권한을 확인하는 일은 별개입니다. AWS의 권고도 이 두 작업을 함께 요구합니다.

업데이트 담당자와 권한 담당자가 함께 끝내야 합니다

먼저 배포 프로젝트의 의존성에서 해당 alpha 모듈과 실제 사용 버전을 확인하는 것이 출발점입니다. 해당한다면 수정 버전 이상으로 업데이트하고, 별도로 복제하거나 변경한 코드에도 수정 사항이 반영됐는지 살펴야 합니다. AWS가 제시한 임시 대응은 관련 설정값에 신뢰할 수 있는 개발자 작성 값만 사용하는 것입니다. 기존 PUBLIC 권한 검토를 대신하는 조치는 아닙니다. AWS 대응 안내

그다음에는 데이터베이스 담당자가 현재 테이블 권한을 의도한 접근 범위와 대조해야 합니다. 버전 변경 내역만 전달하기보다 대상 프로젝트·모듈 버전·관리하는 테이블·설정값의 입력 경로를 함께 남기면 검토 범위가 분명해집니다. 이는 공식 조치를 업무에 적용하기 위한 편집 제안입니다.

PUBLIC 권한을 발견했다고 운영 환경에서 일괄 회수하는 방식은 피하는 편이 좋습니다. 정상 보고서나 연동 작업이 그 권한에 의존할 수도 있습니다. 테이블 소유자와 필요한 계정을 먼저 확인하고, 변경 영향을 시험한 뒤 승인된 절차로 조정하는 것이 안전한 순서입니다. 권한 회수 뒤에도 개별 사용자나 다른 그룹을 통해 같은 권한이 남을 수 있으므로, 최종적으로 해당 계정의 실제 접근 범위를 확인해야 합니다. Redshift 권한 회수 문서

앞서 다룬 Cloudflare Sandbox의 패키지·이미지 업데이트가 실행 환경까지 바꾸는 문제였다면, 이번에는 데이터베이스에 남아 있는 권한이 별도의 확인 대상입니다. 둘을 같은 취약점으로 볼 수는 없지만, 버전 번호 하나로 운영 조치의 완료를 판단하지 않는다는 점은 연결됩니다.

이번 대응의 완료 기록에는 “업데이트했음”뿐 아니라 “어떤 테이블의 권한을, 누가, 어떤 기준으로 검토했는가”도 남아야 합니다. 공식 공지는 취약점의 가능 조건과 수정 방법을 설명합니다. 이를 이미 발생한 침해나 모든 Redshift 사용자의 데이터 유출로 확대해서 해석해서는 안 됩니다.

CONTINUE READING

이 기록에서 이어서 보기

VECTORLOG LETTER

다음 기록도 받아보고 싶다면 구독을 연결해 주세요.

LETTER 구독 안내 →