[AWS] 서버 보안 : 팀원의 EC2 접근, 어떻게 열어줘야 할까?

AWS에서 프라이빗 서브넷에 EC2를 배포하고 Bastion Host를 통해 관리자가 SSH 접속하는 구조는 보안성과 실용성 면에서 굉장히 유리하다.
하지만 실무에서는 혼자만 접속하는 게 아니라, 팀원 혹은 다른 개발자와도 EC2를 함께 사용해야 하는 상황이 생긴다.

"팀원이 내 EC2에 접속하려고 하는데, PEM 키는 공유해도 되는 걸까?"
답은 절대 아니다.

 

이번 글에서는 개발자에게 받은 Public Key를 활용해 별도의 EC2 사용자 계정(backend-dev)을 만들고, Bastion Host를 통해 접속할 수 있도록 구성하는 과정을 소개한다.

---

왜 PEM 키를 공유하면 안될까?

PEM 키는 EC2 인스턴스의 루트 권한에 해당하는 키로, 이를 공유하는 건 비밀번호를 공유하는 것보다 더 위험하다.

1. 접속자 추적이 불가능해지고,
2. 보안 사고 발생 시 책임 소재 파악도 어려워지는 명확한 보안위험성이 있다.

그래서 실무에서는 팀원에게 공개키(Public Key)를 요청해서 등록하는 방식을 사용한다.
더 나아가, 접속하는 유저를 분리하여 EC2 인스턴스에 대한 권한을 최소권한으로 설정한다.

 

EC2 접근 흐름 (요약)

• 관리자: 기존 PEM키 기반 Bastion Host 통해 EC2 접속 가능
• 팀원(개발자): 개인 SSH 키 쌍 생성 (로컬) → 관리자에게 공개키 제공
• 관리자: EC2 개발자 계정 생성 -> EC2 개발자 계정 팀원 공개키 등록
• 팀원(개발자): 개인 SSH PEM 키 기반 Bastion Host 통해 EC2 접속
  

관리자, 팀원 EC2 공개키 등록방법

1. 팀원이 공개키 생성 및 전달

팀원(개발자)는 로컬 CLI에서 아래 프롬프트로 개인 SSH 키 쌍 생성한다.

ssh-keygen -t rsa -b 4096 -C "팀원이름 | 개발직군"

 

생성된 SSH 키 쌍의 Public key 내용을 조회

cat ~/.ssh/id_rsa.pub

 

아래와 같이 Public Key 내용 전체를 복사 후, 관리자에게 전달하면 된다.

 

2. Bastion Host 통해 EC2 접속 (관리자)

관리자는 기존처럼 PEM 키를 이용해 EC2에 접속한다.

ssh -i my-key.pem ec2-user@<bastion-host-ip> ssh ec2-user@<private-ec2-ip>

 

3. EC2에 팀원 계정(backend-dev) 생성

팀원(백엔드 개발자) 계정 생성

sudo adduser backend-dev

 

팀원(개발자) 계정에 SSH 공개 키 등록

sudo mkdir /home/backend-dev/.ssh
sudo nano /home/backend-dev/.ssh/authorized_keys

 

nano 편집창에 전달받은 팀원의 공개키 텍스트 내용을 authorized_keys에 붙여넣기

OS 리눅스 기준 Ctrl + X + Y + Enter 로 저장

 

4. 팀원의 SSH 접속 가이드

팀원은 자신의 프라이빗 키를 사용해서 다음처럼 접속이 가능하다.

ssh -i ~/.ssh/id_rsa backend-dev@<bastion-host-ip> -J ec2-user@<private-ec2-ip>

 

백엔드 프라이빗 EC2 환경이면, 다음처럼 RDS에 접속할 수 있다.

ssh -i ~/.ssh/id_rsa -L 3306:<RDS 엔드포인트>:3306 -J 
backend-dev@<Bastion Host IP> backend-dev@<Private EC2 IP>

 

해당 방식은 SSH 터널링으로 우회하여 프라이빗 RDS에 접근한다.

SSH 터널링으로 접근 시, 로컬 포트를 AWS 내부 리소스 RDS와 연결된다.

 

결과적으로 개발자는 로컬에서 DB URL를 localhost:3306에 접속하면
Bastion Host -> 프라이빗 EC2 -> RDS로 최종 연결된다.

 

보안과 협업의 균형

• EC2 인스턴스 내 권한을 유저별로 나누면 작업 추적이 용이하고, 실수로 인한 사고를 줄일 수 있다.
• backend-dev 계정은 기본적으로 sudo 권한이 없다. 필요하다면 sudo 그룹에 추가하거나 제한된 명령어만 허용한다.
• 다중 유저 환경에서 auditd, history, authorized_keys 주기적 관리도 추천하고 있다.

---

마치는 글

프라이빗 EC2는 Bastion Host를 통해 접속하는 것만으로도 이미 기본 보안이 갖춰진 구조지만,
팀 단위 협업 환경이라면 계정 분리와 SSH 공개키 등록을 통해 더 탄탄한 구조로 발전 시킬 수 있다.

 

이는 단순한 편의성이나 보안 강화 차원을 넘어,

실무에서 자주 언급되는 ""최소 권한 원칙(Least Privilege Principle)""을 실현하는 중요한 접근 방식이다.

즉, 각 팀원이 자신에게 필요한 범위 내에서만 접근하고 작업할 수 있도록 제한함으로써,

보안 사고의 가능성을 줄이고, 책임 있는 협업 환경을 만드는 기반이 된다.

 

보안을 지키면서도 유연하게 협업할 수 있느 구조

이게 바로, AWS에서의 "접근 설계"가 가져다주는 가치이다.

 

조직 구조도 이해관계 / 신뢰관계

더 나아가 이런 구조는 단순히 기술적인 통제를 넘어, 조직 내에서의 ""이해와 신뢰""에 기반한 협업 문화를 가능하게 한다.

신뢰는 통제 없는 자유에서가 아니라, 서로의 역할과 책임이 명확할 때 더 단단해진다.

 

서비스 프로덕트 차원에서, 리스크 관리는 외부적 요인도 있지만, 내부적 요인도 있다는 것

우리는 ""최소 권한 원칙""에 기반해 내부통제를 수행할 수 있다. VPC, 직군별, 접근방식 분리를 통해 이를 수행할 수 있다.