<aside>
프로젝트할 때, EC2를 만들때 디폴트 VPC를 건드리지도 않고 작동된 이유가 디폴트 VPC내의 4개의 subnet은 다 igw에 연결이 되어있어서 되는 거잖아. 그럼 이때, 만들어진 EC2는 public에 놓여있어서 보안이 작동이 안되는거 아니야?
</aside>
EC2의 IP주소가 인터넷에 노출됨 (Public 영역에 존재하기 때문에)
default VPC에 만든 EC2는 Public IP를 부여받기 때문에, 서버의 IP 주소만 알면 서버 앞까지 찾아올 수 있다.
첫 번째 방어막: Security Group
EC2를 감싸고 있는 Security Group이라는 방화벽 덕분에 안전함.
기본 차단 원칙: 보안 그룹은 기본적으로 모든 외부 접속을 100% 차단 -> 기본적으로 인바운드 규칙이 Deny 되어있음
선택적 허용: 개발자가 직접 22번 (SSH), 80번 (HTTP), 443 (HTTPS) 포트만 허락.
<aside>
웹 서비스용 80번 포트만 열면 어떻게 동작을 하는거야? 해커가 80번 포트를 타고 해킹을 시도할 수 있는거 아니야?
</aside>
1차 방어: “할 수 있는 행동의 제한” (프로토콜 격리)
해커가 컴퓨터를 완전히 장악하려면 리눅스 시스템에 직접 명령(rm-rf 등)을 내려야한다. 보통 이런 명령은 22번 포트(SSH)를 통해 이루진다. → 이거는 .pem 키로 해결한다.
하지만 80번 포트는 오직 HTTP만 통과시키는 전용 통로이다. 해커가 80번 포트로 들어와서 리눅스 커널을 건드리거나 서버의 전원을 끄는 시스템 명령어를 던져봤자, 80번 포트에서 대기하고 있던 Nginx는 웹 요청(GET/POST)이 아니네? 하면서 버려버린다.
2차 방어: “애플리케이션 해킹의 영역”
그렇다면 해커는 Nginx의 80번 포트에 맞게끔 HTTP를 사용해서 교모하게 공격을 시도할 수 있다. 이게 바로 웹 보안 위협이다.
SQL Injection, XSS(교차 사이트 스크립팅), DDos 등 공격을 하면 Security Group이 해줄 수 있는 일이 없기는 하다. 왜냐하면 어찌됐든 80번 포트로 들어온 정상적인 HTTP 요청이기 때문이다.
이렇기에 Spring Boot 환경에서 JPA를 사용하면 쿼리 파라미터가 자동으로 이스케이프 처리되어 SQL Injection을 방아해주거나, Nginx는 특정 IP의 접속 횟수를 제한하여 DDos 공격을 막아내는 조취를 취하고 있다.
두 번째 방어막: 비밀번호 없는 SSH 키 페어(.pem)
만약 해커가 22번 포트를 통해 비밀번호를 무차별 대입한다면은?
이를 막기 위해 AWS는 기본적으로 ID/비밀번호 방식의 로그인을 막아두었다. 대신 EC2를 처음 만들 때 다운로드 했던 .pem 키 파일을 가진 사람만 서버 내부에 접속할 수 있도록 암호화 처리를 해두었다. 이 파일이 없으면 22, 80, 443 포트가 열려있어도 접속이 불가능하다.