티스토리 뷰
발생일: 2018.04.08
키워드: AWS Security Group, 보안 그룹, 시큐리티 그룹, nested security group
문제:
AWS 보안 그룹에 다른 보안 그룹을 추가했는데, 하위 보안 그룹의 룰셋이 상위 보안 그룹에 추가되는 것 같지 않다.
왜 그런 걸까?
해결책:
보안 그룹 내에 다른 보안 그룹을 추가하는 경우,
- 하위 보안 그룹의 룰셋이 상위 보안 그룹의 룰셋에 추가되는 것이 아니라,
- 하위 보안 그룹을 가진 인스턴스들이 상위 보안 그룹에 액세스할 수 있게 된다.
오해하기 쉬워 보인다. @_@
참고:
AWS: 10 Things You're Probably Doing Wrong as ans Architect
논의:
종종 보안 설정이 헷갈렸던 이유는, 보안 그룹을 룰셋으로 설정할 때도 있고, 대상 인스턴스의 IP 목록으로 설정하는 경우도 있었기 때문이다.
아래처럼 정리하면 편리할 것 같다.
- VPC를 대표하는 default 그룹을 생성. default 그룹은 모든 인스턴스가 갖도록 한다.
- 각 인스턴스의 그룹은 그룹을 대표할 수 있는 이름(예: app, rds, redshift, redis, jenkins-slave 등)을 보안 그룹으로 갖게 한다.
- 즉, 이 보안 그룹은 룰셋인 동시에 해당 인스턴스의 목록이 된다.
- 해당 보안 그룹의 Inbound 룰에 AWS 인스턴스로부터의 접근 권한을 지정한다.
- 예) 특정 인스턴스의 접근만 허용할 거라면, 해당 보안 그룹을 추가하는 방식으로 넣어준다.
- 예) 모든 인스턴스의 접근을 허용할 거라면 default 그룹을 추가한다.
- VPC 외부의 IP를 명시하는 보안 그룹은 별도로 만들고, (보안 그룹이 아니라) 인스턴스에 지정한다.
- 이 보안 그룹은 외부 IP에 대한 룰셋이므로 별도의 접두사를 둔다.
예) ext_office: 사무실 IP 룰 목록
- 예를 들어, app 인스턴스엔 default, app, ext_office 보안 그룹이 할당되어 있다.
반응형
댓글
공지사항