인증은 현재 사용자가 누구인지 식별하는 과정이다. 보통 로그인하는 과정을 떠올리면 된다.
인가는 인증된 사용자가 해당 기능을 실행할 수 있는지 권한을 체크하는 과정이다.
IAM(Identity And Management)는 AWS의 리소스에 접근할 때, 앞서 서술한 인증과 인가 단계를 컨트롤하는 서비스다.
AWS에서 계정 처음 생성하게 된다면, 그 계정은 AWS의 모든 리소스에 접근할 수 있는 루트 계정일 것이다.
만약 루트 계정이 뚫리게 된다면, 모든 리소스에 접근이 가능하게 되므로 루트 계정을 서비스에 사용하지 않고, IAM을 통해 어떤 기능을 수행할 때 필요한 최소 권한만 가진 사용자를 생성해 서비스에 사용하게 하여 보안성을 강화하는 개념인 것으로 보인다.
사용자별로 권한을 부여할 수도 있지만, 만약 사용자가 엄청 많아질 경우 각각 권한을 부여해주는 것은 여간 귀찮은 일이 아닐 것이다.
또한, 사람이 직접 부여해주는 과정을 거치다보니 필요한 권한을 빼놓을 수도 있는 노릇이다.
이러한 경우를 위해, 그룹이란 개념이 존재한다.
그룹을 생성하여, 해당 그룹이 사용해야할 권한을 설정한 다음, 해당 그룹에 새롭게 들어오는 사람이 있다면 사용자를 그룹에 할당하여 해당 그룹의 권한을 모두 가질 수 있게 해주는 것이다.
aws 페이지에 로그인 할 경우에는 IAM 사용자의 아이디와 비밀번호를 통해 접속하여 컨트롤 할 수 있지만, aws cli나 CI/CD 파이프라인 구축 시에 aws에 구성해놓은 리소스에 접근하기 위해서는 Access Key를 발급받아야 한다.
이러한 Access Key는 아이디 패스워드와 마찬가지로 인증을 받을 수 있는 민감한 정보이므로 루트 사용자의 액세스키를 서비스에 사용하는 일은 지양해야 하며, 외부에 노출되지 않도록 각별히 주의해야 한다.
GitHub에서 CI/CD 파이프라인 구축을 위해 파이프라인 스크립트에 바로 Access Key를 작성하는 것이 아닌, Secrets 같은 서비스를 이용하여 한번 감싸는 것이 좋을 것이다.
AWS에는 권한을 정의하는 정책이라는 객체를 가지고 있다. 사용자나 그룹에게 해당 정책을 부여하게 되면, 영구적으로 권한을 가지게 된다. 반면에 역할은 단기간 동안 특정 권한을 부여하는 자격 증명이다.
정책을 부여한 사용자가 해킹당하게 된다면, 영구적으로 부여된 권한으로 인해 계속해서 AWS의 리소스에 접근이 가능할 것이다.
하지만 역할을 부여한 사용자가 해킹당하게 된다면, 시간이 지나면 권한이 회수되어 리소스 접근에 제약이 생기게 된다.
이러한 정책과 역할의 차이를 이해하면, 클라우드의 보안과 관리에 있어 이점을 가져갈 수 있을 것으로 보인다.