내 AWS EC2가 안전하다고 생각했지만 — 보안 그룹을 확인하기 전까지

Source: Dev.to

왜 나는 내 EC2 인스턴스가 안전하다고 생각했는가

많은 초보자들처럼 나는 작동시키는 데에 집중했다:

• EC2 인스턴스가 성공적으로 시작됨
• SSH 접속이 정상 작동함
• 애플리케이션에 접근 가능

그때 나는 보안은 “처리되었다”고 가정하고 넘어갔다.
처음에 내가 하지 않은 것은 인스턴스를 설정하면서 만든 기본값과 편의성 위주의 선택들을 의심해 보는 것이었다. 여기서 문제가 시작되었다.

처음에 사용한 보안 그룹 설정

EC2 인스턴스를 만들 때 나는 다음과 같은 규칙으로 인바운드 트래픽을 허용했다:

• SSH (포트 22) → Source: 0.0.0.0/0
• HTTP (포트 80) → Source: 0.0.0.0/0

당시에는 이것이 합리적으로 보였다:

• 인스턴스에 접근해야 했음
• 연결 테스트가 필요했음
• AWS가 경고 없이 허용했음

하지만 실제 의미는 훨씬 더 심각했다.

보안 그룹을 검토한 뒤 깨달은 점

보안 그룹은 상태를 유지하는 가상 방화벽으로 EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어한다.
0.0.0.0/0에서 트래픽을 허용함으로써 나는 사실상 다음과 같이 선언한 것이다:

“인터넷에 연결된 누구나 내 인스턴스에 접속을 시도할 수 있다.”

여기에는 다음이 포함된다:

• 자동 스캐너
• 열린 포트를 탐색하는 봇
• 잘못 구성된 시스템을 찾는 악의적인 행위자

EC2 인스턴스 자체는 변하지 않았지만, 내 이해는 변했다.

내가 저지른 주요 실수

1. 과도하게 허용된 인바운드 규칙

어디서든 SSH를 허용하는 것은 가장 흔한 초보자 실수 중 하나다. 바로 공격을 받지 않더라도 위험은 항상 존재한다.

2. 보안 그룹을 설정 양식처럼 다룸

보안 그룹 구성을 보안 경계가 아니라 체크박스 작업으로 생각했다.

3. 최소 권한 원칙 부재

편의를 위해 실제 필요보다 더 많은 접근을 허용했다.

EC2 인스턴스를 안전하게 만들기 위해 바꾼 점

SSH 접근 제한

• 특정 IP 주소에서만 SSH 허용
• 전역 접근 차단

인바운드 규칙을 신중히 검토

• 필요한 포트만 열어 둠
• 사용되지 않거나 임시 규칙 삭제

보안 그룹을 살아있는 제어 수단으로 취급

• “설정하고 잊어버리기”가 아니라 정기적으로 검토
• 실제 사용에 따라 규칙 조정

이러한 변경으로 인스턴스 노출이 즉시 감소했다.

더 큰 교훈: AWS는 당신을 대신해 보안을 제공하지 않는다

내가 깨달은 중요한 점은 다음과 같다: AWS는 도구를 제공할 뿐이며, 그 도구를 얼마나 안전하게 사용하는지는 사용자에게 달려 있다.
EC2는 강력하지만 사용자가 다음을 이해한다고 가정한다:

• 네트워킹 기본
• 접근 제어
• 노출 위험

보안 그룹은 고급 기능이 아니라 기본적인 기반이다.

이 내용이 중요한 대상

이 교훈은 특히 다음과 같은 사람들에게 중요하다:

• AWS 초보자
• 실습 프로젝트를 통해 클라우드를 배우는 사람
• 처음으로 EC2를 배포하는 사람
• 실제 클라우드 업무를 준비 중인 사람

보안 그룹을 일찍 이해하면 나중에 더 큰 문제를 예방할 수 있다.

다음에 개선할 점

이번 경험을 통해 기본 설정을 넘어 생각하게 되었다:

• 직접 SSH 대신 bastion host 사용
• 보안 검사 자동화
• 모니터링 및 로깅 추가
• 공개 노출을 완전히 없애는 아키텍처 설계

보안은 일회성 작업이 아니라 지속적인 실천이다.

마무리 생각

내 EC2 인스턴스가 불안전했던 이유는 AWS가 실패했기 때문이 아니다.
내가 허용한 내용을 충분히 이해하지 못했기 때문이다.

보안 그룹을 확인하는 데는 몇 분이면 충분하지만, 심각한 문제를 예방할 수 있다.
AWS를 배우고 있다면, 먼저 여기서 시작하라.