DNS 서비스(Route 53) 이용
아마존 웹 서비스를 사용하여 웹 서비스를 구성하면 일반적으로 EC2 인스턴스와Elastic Load Balancer를 사용하여 구성을 하게 됩니다.그러면 제일 처음 만나게되는 서버의 주소는 xxx.ap-northeast-2.elb.amazonaws.com와같은 ELB의 DNS name을 사용하게 됩니다. 이는 굉장히 길고 복잡한 주소이기 때문에 사용자로부터 접근성을 떨어뜨리게 되기 때문에 좋지 않습니다. 접근하기 쉬운 주소를 제공하기 위해 먼저 Route 53의 도메인서비스를 사용하여 주소를 할당 받도록 하였습니다. DNS 서비스 이용 시에는 AWS에서 도메인을 구매하여 사용할 수도 있고, 외부 업체를 통해 구입한 도메인의 경우에는 해당 업체의 Name Server설정을 AWS의 Name Server로 설정함으로써 사용이 가능합니다. 도메인을 등록하더라도 ROOT DomainServer까지 반영되기 까지는 1~2일 정도의 시간이 소요될 수 있습니다. 접속이 되지 않을 경우 nslookup 명령을 통해 Name Server 등록이 잘 되었는지 확인할 수 있습니다. Route 53을 통해 서브 도메인을 사용하기 위해서는 Record Set을 생성해야 하는데 IP주소의 경우 A Type을 선택하여 생성하고, DNS name의 경우에는 CNAME Type을 선택하여 생성합니다. 여기서는 ELB의 DNS name을등록해야 하기 때문에 아래와 같이 CNAME 레코드를 생성합니다.
Route 53을 통해 아래와 같이 아키텍처를 구성 할 수 있습니다.
사내에서 사용하는 모든 도메인은 Route 53으로 레코드를 추가해서 사용하였습니다. Route 53을 사용하게 되면 서버의 주소가 변경되어도 사업부나 클라이언트 팀에 변경된 주소를 알릴 필요 없이 Route 53에 주소만 갱신하면 되기 때문에 주소와 관련된 부분은 필수적으로 Route 53을 활용해야 한다고 생각합니다.
보안에 대한 기초 구성
외부 접근 최소화
웹 서버가 구동 중인 EC2 인스턴스는 Private Subnet으로 이전하여 외부에서의 접근을 완전히 차단하는 것이 좋습니다. 하지만 이렇게 될 경우 개발자나 관리자들 또한 해당 EC2 인스턴스로 SSH 접근이 불가능하기 때문에 관리적인 측면에 있어서 문제가 발생하게 됩니다.이러한 경우에는 일반적으로 Bastion이라 불리는Public Subnet에 속한 관리용 EC2 인스턴스를 통해 내부 네트워크 통신으로 웹서버가 구동 중인 EC2 인스턴스로 접속하는 방법이 있습니다. 이때 Security Group 설정을 해당 관리자의 IP만을 허용하도록 하여 다른 외부 접근을 차단하도록 해야 합니다. 이렇게 구성을 하게 되면 외부에서는 서비스중인 EC2 인스턴스로 접근할 방법이 없기 때문에 대량의 악의적인 트래픽에 대해 안전하고, 보안이 강화되는 이점이 있습니다.
Private Subnet에 속한 EC2 인스턴스는 인터넷에 연결되어 있지 않기 때문에 보안 패치나 OS 업그레이드조차 불가능합니다. 이 경우에는 NAT Gateway를 사용하여 Public Subnet을 통해 외부로의 통신이 가능하도록 설정하면Private Subnet의 EC2 인스턴스에서는 외부와 통신할 수 있지만 외부에서는 Private Subnet으로 접속할 Public IP가 존재하지않기 때문에 인터넷을 사용하면서도 여전히 보안을 강화할 수가 있습니다. NAT를 이용하기 위해서는 외부와 통신할 고정된 IP가 필요하기 때문에 NAT Gateway에 Elastic IP할당을 해야합니다. VPC 설정을 위 그림과 같은 구조로 설계하면 고객은 ELB를 통해서만 서버에 접근을 할 수 있고, 개발자 및 관리자들은 Bastion 서버를 통해야만 서버에 접근할 수 있기 때문에 외부로부터의 접근을 최소화 할 수가 있습니다.
키 관리
Key-Pair는 공개키 암호화 방식을 사용하며 Key-Pair 생성 시 다운로드받게 되는 비밀키를 통해서만 복호화가 가능합니다. 즉 비밀키를 소유한 사용자만이 해당 EC2 인스턴스에 SSH로 접속이 가능합니다. 이 비밀키는 AWS 상에 사본이 저장되지 않기 때문에 비밀키를 분실하면 복구할 방법이 없고, 유출 시에는 로그인 정보를 탈취당할 수 있기 때문에 비밀키 관리에 주의해야 합니다.
Key-Pair를 분실한 경우에는 해당 키를 제거하고 교체하는 작업을 진행해야 합니다. EC2 인스턴스에 접속하지 못하기 때문에 새로운 Key-Pair를 적용하기 위해서는 AMI를 생성한 후 EC2 인스턴스를 새로 생성하는 과정에서 새로 생성한 Key-Pair를 할당하거나, EBS 볼륨을 Detach 한 후에 새로 생성된 EC2 인스턴스에 Key-Pair 적용 후 다시 EBS 볼륨을 Attach하여 기존 데이터를 유지할 수 있도록 하는 방법이 있습니다. AMI를 생성하는 과정에서는 현재 구동 중인 EC2 인스턴스를 재시작하지 않고도 생성이 가능하지만 생성 과정중에 EC2 인스턴스의 변경사항에 의한 데이터 불일치가 발생할 수 있기 때문에 EC2 인스턴스를 중지 후에 진행하는 것이 좋습니다. 키를 추가하거나 갱신하는 경우에는 EC2 인스턴스에 접속하여 ~/.ssh/authorized_keys 파일을 수정하는 것으로 적용할 수 있습니다. 예를들어 새로 생성한 Key-Pair를 추가하는 경우 비밀키 이름이 updatekey.pem이라면 아래와 같이 추가가 가능합니다.
$ ssh-keygen -y -f updatekey.pem >> .ssh/authorized_keysEC2 인스턴스를 중지 시키고 다시 시작하는 경우 대부분 새로운 호스트 머신에서 EC2 인스턴스가 생성되고 기존에 사용했던 EBS 볼륨을 마운트하여 데이터를 유지하기 때문에 Elastic IP를 지정하지 않은 경우에는 Public IP가 변경되어 해당 주소를 사용하는 곳이 있다면 서비스에 장애가 발생할 수 있습니다. Private IP의 경우에는 EC2 인스턴스를 재시작하여도 변경되지 않으므로 내부 통신에 있어서는 IP 변경의 위험 없이 사용할 수 있습니다. 현재 저희의 웹 서버가 있는 EC2 인스턴스로의 접근은 ELB를 통해서 이루어지기 때문에 Public IP를이용하는 곳이 존재하지 않기 때문에 Elastic IP는 사용하지 않았습니다.
IAM을 통한 권한 관리
IAM은 AWS의 보안 인프라 구성 요소 중 하나입니다. IAM을 사용하면 AWS의 서비스와 리소스에 액세스 할 수 있는 권한 정책을 구성하여 중앙에서 관리할 수가 있습니다. 그룹 단위로 권한을 부여하여 사내의 각 팀의 역할에 맡게 권한을 부여할 수 있고, CloudTrail을 통해 각 사용자들이 어떠한 행위를 했는지를 빠짐없이 검토할 수도 있습니다. 이와 같은 구성은 협력, 커뮤니케이션, 투명성을 위해 반드시 필요한 사항이기 때문에 개발 초기부터 적용하는 것이 좋습니다. 아래와 같이 각 부서별로 부여할 권한을 그룹으로 관리하고 IAM 계정에 할당하여 다른 서비스들에 영향을 줄 수 없도록 설정하면 사내 직원들의 실수로 인한 서비스 장애를 방지할 수가 있습니다.
루트 계정으로의 로그인은 가급적 피하는 것이 좋고, OTP 인증과 같은 2차 보안 인증을 통해 보안을 강화하는 것이좋습니다. IAM 대시보드를 확인하면 아래와 같이 보안에 대한 지침사항들이 표시가 됩니다. 여기서 경고하는 루트 계정 권한이나 강력한 패스워드 정책 등에 대한 지침들을 하나씩 해결해 나감으로써 보안을 강화하는 것이 좋습니다.
IAMRole을 생성하여 사용자뿐만 아니라 AWS 서비스들에도 권한을 설정할 수 있습니다. 예를 들어 S3에서 특정 EC2 인스턴스를 제외한 모든 접근을 차단하는 Role을 적용하여 정해진 경로를 통해서만 업로드가 가능하도록 하거나, Elasticsearch 서비스에 특정 관리자만 write가 가능하도록 Role을 적용할 수도 있습니다. 이와 같이 최초 루트 계정만으로 접근하던 것을 피하고, 최소한의권한으로 AWS 서비스를 이용하는 것이 중요합니다.
참고
같이 보면 좋은 포스팅
하이브 런칭기 #6 - 부하테스트
하이브 런칭기 #7 - 로그 관리 및 지표/통계
'Work > 개발 노트' 카테고리의 다른 글
| 하이브 런칭기 #4 - 오토스케일링 및 알림 설정 (0) | 2018.08.15 |
|---|---|
| 하이브 런칭기 #3 - 데이터베이스 구성 (0) | 2018.08.15 |
| 하이브 런칭기 #1 - 사내 환경 구성 (0) | 2018.08.15 |
| jenkins build history cleanup (0) | 2017.05.22 |
| StartSSL을 통한 인증서 생성 (0) | 2016.10.07 |
댓글