권한 관리

01

누구냐, 무엇을 해도 되냐: 인증과 인가

회사 건물에 들어갈 때를 생각해 봅시다. 입구에서 사원증으로 본인인지 확인하고, 층마다 그 사원증으로 들어갈 수 있는 곳인지 다시 확인합니다. 앞의 것이 인증(Authentication, 누구인지 확인), 뒤의 것이 인가(Authorization, 그 사람이 이 일을 해도 되는지 결정)입니다. 클라우드도 똑같이 두 단계를 거칩니다.

요청을 보내는 쪽을 보안 주체(principal), 줄여서 주체라고 부릅니다. 주체는 사람만이 아닙니다. 매일 밤 백업을 도는 프로그램, 주문을 처리하는 서버도 클라우드의 저장소나 데이터베이스를 부르니 모두 주체입니다. 사람에게는 비밀번호와 두 번째 확인 수단을, 프로그램에게는 키나 임시 자격 증명을 줘서 누구인지 밝히게 합니다(4장). 아래 그림에서 상황을 바꿔 보세요.

HTTP 표준에서는 401이 인증 실패(누구인지 다시 밝혀라), 403이 인가 실패(알지만 허락하지 않는다)를 뜻합니다. 그런데 클라우드 API는 이 구분을 그대로 따르지 않기도 합니다. 둘 다 403으로 돌려주는 곳도, 둘 다 401로 돌려주는 곳도 있습니다. 그래서 상태 번호보다 오류 코드와 메시지를 보고 어느 문에서 막혔는지 가립니다.

가장 강한 계정은 쓰지 않는 계정

클라우드 계정을 처음 만들 때 생기는 최상위 계정(루트·메인 계정, 최고 관리자)은 모든 것을 할 수 있습니다. 결제 정보 변경이나 계정 해지까지 됩니다. 그래서 이 계정은 MFA를 걸어 금고에 넣어 두고, 평소 일은 권한을 나눈 별도 계정으로 합니다. 이 계정이 털리면 어떤 권한 설정도 소용이 없기 때문입니다.

누구인지 확인하는 문을 봤습니다. 그런데 직원이 쓰는 앱이 수십 개라면, 그 문을 앱마다 따로 세워야 할까요?

02

신원 하나로 모으기: SSO·페더레이션·MFA·조건부 접근

앱마다 계정과 비밀번호를 따로 두면 비밀번호가 늘고, 사람들은 같은 비밀번호를 돌려 씁니다. 퇴사자가 생기면 앱마다 찾아가 계정을 지워야 하고, 하나라도 빠뜨리면 그 문은 계속 열려 있습니다. 그래서 신원은 신원 공급자(IdP) 한 곳에 모읍니다. 로그인은 IdP에서 한 번만 하고, 앱들은 IdP가 발급한 확인서(토큰)를 믿고 들여보냅니다. 이것이 SSO(Single Sign-On)입니다.

회사가 이미 사내 디렉터리를 쓰고 있다면 클라우드에 사람을 새로 만들지 않고 그 디렉터리를 믿게 할 수 있습니다. 이렇게 다른 조직의 신원 확인을 믿는 것을 페더레이션이라 하고, 그 확인서를 주고받는 표준이 SAML 2.0과 OIDC(OpenID Connect)입니다.

비밀번호 하나로는 부족하다: MFA

비밀번호는 피싱으로, 유출된 다른 사이트 비밀번호로 쉽게 새어 나갑니다. MFA(다단계 인증)는 비밀번호에 더해 내가 가진 것(휴대폰 앱, 보안 키)이나 나 자신(지문)으로 한 번 더 확인합니다. 같은 MFA라도 강도가 다릅니다. 문자(SMS)나 인증 앱의 6자리 숫자는 가짜 사이트에 그대로 입력해 넘어갈 수 있지만, 보안 키와 패스키(FIDO2)는 진짜 사이트에서만 동작해 피싱에 강합니다.

상황을 보고 정하기: 조건부 접근

로그인할 때마다 같은 강도로 확인할 필요는 없습니다. 회사 노트북으로 사무실에서 들어오면 그냥 통과시키고, 처음 보는 나라와 기기에서 들어오면 MFA를 요구하거나 막을 수 있습니다. 이렇게 사용자·위치·기기·위험도 같은 신호를 보고 "허용 / 추가 확인 후 허용 / 차단"을 정하는 것이 조건부 접근입니다. 신원이 한곳(IdP)에 모여 있어야 이런 조건도 한곳에서 걸 수 있습니다.

누구인지는 확실해졌습니다. 이제 둘째 문, "이 일을 해도 되냐"를 정하는 정책을 읽어 봅시다.

03

정책 읽는 법: 누가·무엇을·어디에·어떤 조건에서

권한은 정책으로 줍니다. 프로바이더마다 모양은 달라도 정책이 담는 칸은 거의 같습니다. 누가(주체), 무엇을(행동), 어디에(리소스), 어떤 조건에서(조건), 그리고 허용인지 거부인지입니다.

허용 | 누가: 개발자 그룹
     | 무엇을: 객체 읽기, 객체 쓰기
     | 어디에: 개발용 버킷의 모든 객체
     | 조건: MFA로 로그인했을 때만

요청이 들어오면 시스템은 그 요청에 해당하는 정책을 모두 모아 대조합니다. 판정 규칙은 세 줄입니다.

아래 그림에서 허용 정책과 거부 정책을 붙였다 뗐다 해 보세요.

정책을 붙이는 두 자리: 신원 쪽과 리소스 쪽

정책은 사람·그룹·역할 같은 신원에 붙이기도 하고("이 사람은 무엇을 할 수 있다"), 저장소 같은 리소스에 붙이기도 합니다("이 버킷에는 누가 들어올 수 있다"). 리소스 쪽 정책에는 "누가" 칸이 꼭 들어갑니다. 리소스 쪽 정책은 다른 계정·조직의 주체를 들일 때 특히 중요해서 5장에서 따로 봅니다.

사람마다 주지 말고 묶어서 주기: 그룹과 역할

정책을 사람 한 명 한 명에게 붙이면 사람이 늘수록 관리할 수 없게 됩니다. 같은 일을 하는 사람을 그룹으로 묶어 그룹에 붙이고, "읽기 전용", "데이터베이스 운영자"처럼 권한 묶음을 역할로 만들어 주는 것을 역할 기반 접근 제어(RBAC)라고 합니다. 여기에 태그 같은 속성을 조건으로 써서 "프로젝트 태그가 같은 리소스만"처럼 주는 것을 속성 기반 접근 제어(ABAC)라고 합니다.

정책은 사람에게만 붙는 게 아닙니다. 사람 없이 밤새 도는 프로그램에게는 어떻게 권한을 줄까요?