Loading the catalog…
Loading the catalog…
관리 콘솔에 들어갈 수 있다는 것과, 매일 최고 권한으로 일해야 한다는 것은 다른 문제입니다. 배포 담당자에게 루트 계정이나 장기 액세스 키를 나눠 주면 업무가 끝난 뒤에도 같은 비밀이 남습니다. 이번 글에서는 누가 로그인하는지, 어떤 역할을 맡는지, 언제 권한이 끝나는지 를 분리해 보겠습니다. AWS 계정과 IAM 역할의 이름 정도를 알고 있으면 읽을 수 있습니다. 기존 AWS 시리즈 가 서비스 연결을 살펴봤다면, 여기서는 그 연결을 시작하는 사람의 접근부터 좁힙니다. 사람의 로그인과 프로그램의 로그인 사람은 IAM Identity Center나 외부 자격 증명 공급자를 통한 연동 로그인을 사용하고, 필요한 계정의 역할로 임시 자격 증명을 받는 흐름을 검토합니다. 프로그램은 사람이 쓰던 키를 복사하기보다 실행 환경에 맞는 IAM 역할을 사용합니다. 둘 다 장기 비밀을 줄이는 방향이지만 인증 방법까지 동일한 것은 아닙니다. IAM 보안 권장 사항 MFA는 다중 요소 인증입니다. 비밀번호만 알아서는 로그인할 수 없게 하는 추가 장치입니다. Identity Center의 자격 증명 원본이 무엇인지에 따라 MFA 설정 위치를 확인해야 합니다. 외부 IdP를 쓰면서 다른 화면의 MFA 체크만 켰다고 실제 사람의 로그인에 적용됐다고 판단하면 안 됩니다. 그림의 마지막 칸은 권한이 영구 저장되는 지점이 아닙니다. 역할 세션에는 수명이 있습니다. 다만 이미 발급된 세션의 처리와 새 로그인 차단은 별도로 확인해야 합니다. 계정 할당을 없앴다는 이유만으로 모든 세션이 즉시 끝났다고 가정하지 않습니다. 한 시간짜리 조회 역할의 예 아래 JSON은 CloudFormation의 AWS::SSO::PermissionSet 리소스 조각 입니다. 가상 ARN이며 배포용 전체 템플릿이 아닙니다. 실제 Identity Center 인스턴스, 사용자·그룹의 계정 할당, MFA 설정은 포함하지 않았습니다. { "Type": "AWS::SSO::PermissionSet", "Properties": { "InstanceArn": "arn:aws:sso:::instance/ssoins-0123456789abcdef", "Name": "StudyEc2Inventory", "SessionDuration": "PT1H", "InlinePolicy": { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["ec2:DescribeInstances"], "Resource": "*" }] } } } PT1H 는 ISO 8601 형식의 한 시간입니다. 정책은 EC2 인스턴스 목록 조회만 예로 들었습니다. 이 조회 API는 리소스별 ARN으로 제한하는 방식이 지원되지 않아 Resource 가 * 입니다. 모든 작업을 허용하는 Action: "*" 와는 뜻이 다릅니다. 정책을 읽을 때 별표 하나만 보고 판단하기보다 작업별 지원 범위를 확인해야 합니다. PermissionSet 필드 , EC2 조회 권한의 리소스 제한 이 조각에는 MFA 조건이 없습니다. PermissionSet의 세션 시간 설정이 MFA 설정을 대신하지도 않습니다. 세션이 짧아져도 허용한 작업 자체가 줄어드는 것은 아니므로, 권한 범위와 세션 시간은 따로 검토합니다. 루트 계정은 비상 절차까지 함께 루트 계정은 일반 배포 계정으로 사용하지 않고, 루트가 필요한 작업의 절차를 분리합니다. 루트 액세스 키를 만들지 않고, MFA와 계정 복구 수단을 보호합니다. Organizations의 멤버 계정에서는 중앙 루트 접근 관리가 가능한 구성도 있지만, 독립 계정이나 관리 계정에 같은 절차를 그대로 적용할 수 있다고 가정하면 안 됩니다. 루트 사용자 보호 지침 운영 설계로는 비상 접근 담당자, 승인 방법, 사용 기록, 복구 수단을 정합니다. 정상 IdP가 장애일 때 필요한 경로까지 끊어 놓으면 보안 설정을 되돌릴 사람도 없어질 수 있습니다. 그렇다고 모두에게 상시 관리자 권한을 주는 방식으로 해결하지 않습니다. 적용·확인·되돌리기 현재 사람 계정, 장기 키 사용처, 루트 사용 이유를 목록으로 만듭니다. 비밀 값은 목록에 쓰지 않습니다. 테스트 계정에서 조회 역할을 할당하고 새 로그인에 MFA가 요구되는지 확인합니다. 인스턴스 조회는 성공하는지 확인합니다. 종료 권한 검사는 해당 API의 DryRun 으로 먼저 확인하고 실제 인스턴스를 종료하지 않습니다. 세션 만료 뒤 재인증도 별도 확인합니다. 기존 접근을 제거하기 전에 다른 승인된 관리 경로로 로그인할 수 있는지 점검합니다. 되돌릴 때는 변경한 할당이나 세션 설정을 검토된 이전 상태로 돌립니다. 장기 키를 다시 배포하는 것을 자동 복구 절차로 만들지 않습니다. 탈취된 자격 증명이라면 단순 원복보다 세션 처리와 사고 대응이 우선입니다. 로컬 검증: JSON 구문, 한 시간 세션, 조회 작업만 포함한 조건을 검사했습니다. 세션을 12시간으로 바꾼 반례가 학습용 기준에서 탈락하는 것도 확인했습니다. 실제 로그인, MFA 강제, STS 만료와 AWS 권한 평가는 실행하지 않았습니다. 확인 문제 MFA를 켜면 관리자 권한이 읽기 전용으로 바뀔까요? SessionDuration 을 줄이면 장기 액세스 키가 자동 삭제될까요? IdP 장애에 대비하는 절차에는 어떤 항목을 넣어야 할까요? 답과 해설 아닙니다. MFA는 인증을 보강하고, 허용 작업은 정책이 결정합니다. 아닙니다. 역할 세션 설정과 기존 키 수명은 별도입니다. 승인된 비상 신원, 접근 승인, 복구 수단, 사용 기록, 종료 후 권한 회수 방법입니다. 직접 로그인 검증도 필요합니다. 다시 공부하기 오늘은 사람과 워크로드의 로그인 경로를 따로 그려 보세요. 내일은 예제 역할이 조회만 할 수 있는지 정책을 읽어 보세요. 일주일 뒤에는 MFA와 최소 권한이 각각 막는 문제를 설명해 보세요. 권장 복습 순서이며 자동 알림은 아닙니다. 문서 확인일: 2026-10-04, 한국 시간 . 예제 기준은 IAM Identity Center PermissionSet과 IAM 정책 2012-10-17 입니다. 다음 학습 목표는 역할의 신뢰 정책과 실제 작업 권한을 구분하는 것입니다.
What RADAR observed and classified to build this opportunity. It is what the source published, not a verification that the offer is still active.
[AWS 하드닝 01] 관리자 로그인부터 줄이기: MFA와 임시 자격 증명. 관리 콘솔에 들어갈 수 있다는 것과, 매일 최고 권한으로 일해야 한다는 것은 다른 문제입니다. 배포 담당자에게 루트 계정이나 장기 액세스 키를 나눠 주면 업무가 끝난 뒤에도 같은 비밀이 남습니다. 이번 글에서는 누가 로그인하는지, 어떤 역할을 맡는지, 언제 권한이 끝나는지 를 분리해 보겠습니다. AWS 계정과 IAM 역할의 이름 정도를 알고 있으면 읽을 수 있습니다. 기존 AWS 시리즈 가 서비스 연결을 살펴봤다면, 여기서는 그 연결을 시작하는 사람의 접근부터 좁힙니다. 사람의 로그인과 프로그램의 로그인 사람은 IAM Identity Center나 외부 자격 증명 공급자를 통한 연동 로그인을 사용하고, 필요한 계정의 역할로 임시…
Open source