기업클라우드 도입 전 | 계정·권한·로그의 서비스 개시 승인 기준
기업클라우드에 첫 업무 시스템을 올리기 전에는 ‘접속된다’는 결과보다 누가 승인하고, 무엇을 검증했으며, 어떤 미충족 항목 때문에 개시를 멈출 것인지부터 정해야 합니다. 인프라 책임자·보안 담당자·플랫폼 엔지니어가 함께 계정 분리, 관리자 권한, 통신 경로, 감사 로그를 검토하고 각 항목의 담당자와 증적을 남기는 방식이 적합합니다.
이 글은 공급자 가격이나 보안 제품을 비교하는 대신, 첫 업무 시스템의 서비스 개시 승인 기준을 제안합니다. 구체적인 기능 설명은 AWS 공식 문서를 사례로 사용합니다. 다른 공급자의 계정·프로젝트·구독이 AWS 계정과 같은 통제 경계를 제공한다고 가정하지 말고, 실제 사용할 서비스의 정책 적용 범위에 맞춰 판단표를 작성해야 합니다.
1. 공급자 책임과 우리 운영팀의 책임부터 나눈다
클라우드 공급자가 인프라를 운영한다는 이유만으로 고객의 설정·운영 책임이 없어지는 것은 아닙니다. AWS 책임 공유 모델에서 EC2 고객은 게스트 운영체제의 업데이트와 보안 패치, 설치한 애플리케이션, 보안 그룹 설정을 책임집니다. 책임 범위는 선택한 서비스에 따라 달라집니다.
따라서 개시 회의에서는 ‘클라우드니까 공급자가 처리한다’는 답변 대신 실제 사용할 서비스별로 책임을 나눠야 합니다. 아래는 조직에서 합의할 수 있는 역할 배분 예시이지, 공급자가 정한 필수 조직 구조는 아닙니다.
- 업무 책임자: 서비스에 필요한 사용자·데이터·통신 범위를 설명하고, 미충족 항목이 업무에 미치는 영향을 판단합니다.
- 인프라·플랫폼 담당자: 계정 구조와 접근·통신 설정을 구현하고 시험 결과를 제출합니다.
- 보안 담당자: 권한 범위, 감사 대상 행위, 예외 조건을 검토합니다.
- 개시 승인권자: 미충족 항목의 보완 또는 개시 보류를 결정합니다. 담당자와 완료 기한이 없는 예외를 그대로 넘기지 않는 기준을 권합니다.
근거: AWS 책임 공유 모델 — 2026년 11월 7일 확인.
2. 계정 분리는 개수보다 통제 경계로 판단한다
AWS IAM 모범 사례는 워크로드 규모가 커지면 AWS Organizations로 관리하는 여러 계정으로 워크로드를 분리할 것을 권고합니다. 이를 모든 기업에 동일한 계정 수가 필요하다는 뜻으로 해석할 필요는 없습니다. 첫 시스템에서는 개발·운영 사이에서 무엇이 분리되어야 하는지 먼저 정하는 편이 실용적입니다.
분리 여부를 판단할 때는 ‘개발용’과 ‘운영용’이라는 이름보다 아래 질문에 대한 답을 기록하십시오.
- 개발 담당자의 자격 증명으로 운영 자원을 변경할 수 있는가?
- 운영 데이터에 접근하는 사람과 개발 환경을 관리하는 사람이 같아야 하는가?
- 공통 관리자나 자동화 도구에 여러 환경을 넘나드는 권한이 필요한가? 필요하다면 누가 승인하는가?
- 환경을 함께 두는 예외가 있다면 허용 범위, 만료일, 재검토 책임자는 누구인가?
권장 개시 기준은 ‘계정을 나눴다’가 아니라 ‘허용하지 않은 환경 간 접근이 거부되는 것을 확인했다’입니다. 승인된 시험 계정과 비민감 시험 자원으로 허용 작업과 금지 작업을 각각 수행하고, 기대 결과와 실제 결과를 함께 남기십시오.
근거: AWS IAM 모범 사례 — 2026년 11월 7일 확인. 계정 분리 권고를 참고하되, 실제 통제 범위는 선택한 구조와 정책을 기준으로 시험해야 합니다.
3. 관리자 권한은 발급·사용·회수를 한 묶음으로 승인한다
AWS는 사람의 접근에 역할 기반 임시 자격 증명을 제공하는 연동 방식을 권고하며, IAM 정책에서는 특정 작업에 필요한 권한만 부여하도록 안내합니다. 서비스 개시 시험에도 이 두 원칙을 반영할 수 있습니다. 업무가 성공하는지뿐 아니라 업무 밖 자원에 대한 접근이 거부되는지도 확인하는 것입니다.
다만 임시 자격 증명을 사용한다는 사실만으로 기존 세션까지 즉시 회수된다고 단정하면 안 됩니다. 퇴사·직무 변경·긴급 회수 상황은 별도의 시험으로 다루고, 새 로그인 차단과 이미 발급된 세션의 접근 결과를 구분해 기록하십시오.
- 발급: 요청자, 승인자, 대상 환경, 허용 작업, 사용 기간을 정합니다.
- 사용: 승인한 업무의 성공과 범위 밖 작업의 거부를 확인합니다.
- 회수: 권한 변경 후 새 접근과 기존 세션의 동작을 각각 확인합니다. 의도와 다르면 개시 전에 처리 방식을 결정합니다.
- 긴급 접근: 사용할 수 있는 상황, 사용 결정권자, 사용 후 검토자를 정하고 비상 절차를 시험합니다.
회수 시험은 실제 운영 관리자 접근을 무작정 끊는 방식이 아니라 시험 역할과 복구 가능한 범위에서 수행하는 것을 권합니다. 긴급 접근 역시 ‘비상 계정이 있다’는 설명만으로 완료 처리하지 말고, 사용 책임과 사후 검토까지 승인 대상으로 두십시오.
근거: AWS IAM 모범 사례의 임시 자격 증명·최소 권한 권고 — 2026년 11월 7일 확인.
이번 시스템의 개시 기준을 정한 뒤, 계정 승인·변경·퇴사자 회수를 전사 SSO·MFA·권한 수명주기로 확장하려면 다음 글을 이어서 볼 수 있습니다.
4. 네트워크와 로그는 실제 행위를 기준으로 대조한다
통신 경로: 허용 시험과 거부 시험을 함께 남긴다
EC2 보안 그룹에서 인바운드 규칙은 인스턴스로 들어오는 트래픽을, 아웃바운드 규칙은 나가는 트래픽을 제어합니다. 따라서 계정 권한을 승인했다는 사실과 필요한 통신 경로를 검증했다는 사실은 별도로 다뤄야 합니다.
시험표에는 출발지, 목적지, 방향, 필요한 통신, 기대 결과를 적고 정상 업무 경로와 허용하지 않을 경로를 각각 확인하십시오. EC2 보안 그룹은 상태를 추적하므로 허용된 요청의 응답 트래픽은 반대 방향 규칙과 무관하게 허용될 수 있습니다. 거부 시험 결과를 해석할 때는 새 연결인지 기존 연결의 응답인지도 구분해야 합니다.
근거: Amazon EC2 보안 그룹 문서 — 2026년 11월 7일 확인.
통신 경로의 허용·차단·복원 시험을 더 구체화해야 한다면 접근 통제 검증 체크리스트를 참고하십시오. 여기서는 그 시험 결과를 서비스 개시 승인 증적에 연결하는 데 초점을 둡니다.
감사 로그: 화면에 기록이 보인다는 이유로 완료 처리하지 않는다
AWS CloudTrail의 Event history 화면은 관리 이벤트만 표시하며, 데이터 이벤트·Insights 이벤트·네트워크 활동 이벤트는 표시하지 않습니다. 또한 조직 단위 이벤트 집계를 제공하지 않습니다. 조직 전체 기록이 필요하다면 조직용 이벤트 데이터 스토어 또는 trail을 별도로 검토해야 합니다.
따라서 기업 클라우드 보안 점검에서 ‘로그 조회 화면을 열었다’는 증적은 충분한 개시 기준이 되기 어렵습니다. 먼저 감사해야 할 업무 행위를 정하고, 각 행위에 필요한 기록이 어디에 수집되어야 하는지 대응시켜야 합니다. 설정 변경과 업무 데이터 접근을 하나의 수집 항목으로 뭉뚱그리지 마십시오.
- 시험 전: 대상 행위, 시험 주체, 대상 계정·자원, 예상 기록 위치를 적습니다.
- 시험 후: 수행 시각과 실제 기록을 대조하고 주체·대상·결과를 식별할 수 있는지 확인합니다.
- 누락 시: 조회 범위가 다른 것인지, 해당 행위의 수집 설정이 빠진 것인지 구분한 뒤 재시험합니다.
- 운영 인계: 보관 기간, 조회 권한, 수집 설정 변경 권한의 책임자를 정합니다. 지원 방식은 사용할 서비스의 공식 문서와 실제 설정을 기준으로 판단합니다.
근거: AWS CloudTrail Event history 문서 — 2026년 11월 7일 확인. Event history의 표시 범위와 조직 집계 제한을 근거로 삼았으며, 이 화면만으로 전체 감사 범위를 판단하지 않습니다.
5. 서비스 개시 판단표에는 증적과 보류 조건을 넣는다
다음 표는 내부 승인 회의용 출발점입니다. ‘설정 완료’ 대신 실제 시험 결과를 첨부하고, 각 행에 실명 담당자·시험일·증적 위치·미충족 항목·보완 기한을 추가해 사용하십시오. 아래 보류 조건은 법적 의무나 공급자 인증 기준이 아니라, 첫 업무 시스템을 위한 권장 운영 기준입니다.
| 통제 항목 | 책임 배분 예시 | 필요한 증적 | 개시 보류를 권하는 조건 |
|---|---|---|---|
| 계정·환경 분리 | 플랫폼 구현, 업무·보안 검토 | 환경별 접근 범위와 교차 접근 거부 시험 | 승인하지 않은 운영 자원 변경이 가능함 |
| 관리자 권한 | 권한 관리자 실행, 지정 승인자 승인 | 발급 승인과 최소 권한·회수 시험 결과 | 회수 후 접근 결과를 설명하거나 통제할 수 없음 |
| 긴급 접근 | 운영 책임자 결정, 별도 검토자 사후 확인 | 사용 조건·시험 결과·사후 검토 절차 | 사용 결정권자나 사용 후 검토자가 없음 |
| 네트워크 | 인프라 구현, 업무 경로 확인, 보안 검토 | 출발지·목적지별 허용 및 거부 시험 | 허용하지 않은 경로에서 새 연결이 성공함 |
| 감사 로그 | 업무·보안이 감사 대상 정의, 플랫폼이 수집 구현 | 대상 행위와 실제 기록의 대조 결과 | 필수 감사 행위의 기록이 없거나 누락 원인이 불명확함 |
승인 결과는 개시·조건부 개시·보류로 나눠 기록할 수 있습니다. 조건부 개시를 허용한다면 미충족 항목마다 영향, 임시 통제, 보완 담당자, 기한, 재시험 조건을 명시하십시오. 통제 공백의 영향을 판단할 수 없거나 책임자가 없는 항목은 조건부 승인으로 넘기지 않는 편이 안전합니다.
첫 회의의 목표는 계정과 로그를 모두 새로 설계하는 것이 아닙니다. 먼저 표의 각 행에 담당자를 지정하고, 다음 회의까지 제출할 증적을 정하십시오. 서비스 개시 여부는 기능을 켰는지가 아니라, 합의한 통제가 실제로 작동하는지와 예외를 누가 책임지는지로 결정하는 것이 이 판단표의 핵심입니다.
댓글
댓글 쓰기