AWS에 올린 웹사이트에 사용했던 구글의 API가 주기적으로 초기화되어 검색해봤더니, 해당 API가 테스트 모드로 작동하고 있어서 그렇다고 하더군요. 구글 클라우드 플랫폼에 들어가서 확인해보니 실제로 테스트 모드로 작동하고 있었습니다. 프로덕션 모드 전환은 적용 사이트가 HTTPS를 지원해야 가능했습니다. 그래서, HTTP로 접속되던 사이트를 HTTPS로 보안접속 가능하도록 변경하는 작업을 하게 되었다는 이야기.
이전에도 그랬던 것처럼 상세한 설명은 웹의 엄청난 자료들에게 양보하고, 어떤 작업을 왜 수행해야 하는지에 대한 Skeleton만 다뤄볼께요. 이 내용을 보시고 구조를 이해하신 후 Article 내의 키워드들로 검색해서 작업하시면 크게 어려움 없이 작업이 가능할 겁니다.
HTTPS는 브라우저와 서버 사이의 전송 데이터를 암호화하기 위한 프로토콜이에요. 민감하지 않은 데이터의 경우 HTTP를 사용하도록 되어있지만, 정보보호의 개념이 점차 강화되자 구글의 크롬 브라우저에서는 HTTP 지원 사이트에는 주소표시줄 앞에 ‘안전하지 않음’이라는 문구를 보여주고 있죠.(생각보다 기분 나쁨) HTTPS는 공개키 암호화 방식을 사용하는데, 그러기 위해서 서버는 공개키와 개인키를 준비해야 합니다. 알다시피 개인키는 서버용이고, 공개키는 사용자 배포용이에요. 서버는 – 신뢰도를 높이기 위해 – 사용자용 공개키를 조직 정보와 함께 인증기관(CA)의 인증을 받아 배포합니다.(이것을 인증서라 하는데 이 인증서는 CA의 개인키로 암호화되며, 사용자 브라우저는 해당 인증서를 미리 보유하고 있는 CA의 공개키를 사용해서 복호화합니다. 상세한 작동원리를 알고 싶으면 handshake로 검색을 하시면 돼요.)
위의 인증서가 준비되면 서버 Configuration 도구에서 HTTPS를 지원하도록 설정하고, 인증서를 특정 위치에 저장해둔 후 인증서를 사용하도록 웹서버를 구성하면 됩니다. 그 외에도 HTTP를 HTTPS로 리다이렉션 시킨다던가, 사이트 내외부 URL이 프로토콜에 구속되지 않게 상대 경로를 사용하거나, 경로에서 프로토콜을 제외해야 해요.(예: //192.168.1.56:8081/something.js) 그래야 HTTPS 접속 때 이미지가 안 보이거나 하는 불상사를 막을 수 있습니다.
여기까지는 일반적인 이야기이고, 제 경우에는 웹사이트가 AWS에 올려져 있었기 때문에 아마존의 서비스들을 레버리징 하기로 했습니다. 우선 작업이 편해요. 프리티어 기간이라 비용이 추가로 들지도 않고요. 물론 기본 요즘제에는 트래픽에 비례하여 부과되는 비용 외에 기본료까지 있기 때문에, 아래 방법은 이미 트래픽 문제 해결을 위해 로드밸런서를 적용하고 있는 경우에 유용할 것 같네요.
인증서 작업
인증은 AWS의 Certificate Manager를 통해 무료 SSL/TLS 인증 서비스를 받습니다. CA를 통해 연간 비용을 지불하고/매번 갱신작업을 하는 것보다 훨씬 저렴하고/편리합니다. AWS Certification Manager는 인증기관을 통한 인증서 발급 및 자동 갱신까지 자동으로 수행해주기도 하고요. 인증서 발급 작업 시 Domain name에 name.com 및 *.name.com을 추가하고, e-mail로 인증을 선택을 수행하면 됩니다. 전달된 메일에 동의하면 인증서 발급이 완료돼요.
인증서 설치를 위한 로드발란서 세팅
해당 인증서는 트래픽 분산처리 서비스인 ELB Elastic Load Balancing을 사용해서 배포 지점에 설치할 수가 있습니다. 로드밸런서를 생성하는 방법은 Application Load Balancer를 선택하고, Basic configuration에서 이름을 정한 후, Scheme = Internet-facing, IP address type = IPv4를 선택합니다.
Network mapping에서는 웹서비스 대상 VPC(virtual private cloud)를 선택해주고, Mappings에서 두 개 이상의 AZ(Availaility Zones)를 선택하고, 각 AZ에서 하나의 subnet을 지정해줘요.
Security groups에서는 기본으로 Default security group을 제안하는데 그대로 사용하지 말고, EC2 대시보드에서 해당 인스턴스 보안(탭) 속성의 보안 그룹을 확인하여 동일하게 지정을 해주어야 합니다.(이것을 제대로 지정하지 않으면 브라우저에서 연결이 죽어도 안됨) Listeners and routing에서는 HTTP와 HTTPS를 모두 지정해주고, 적절한 타깃 그룹을 생성해 연결해주면 됩니다. 그리고, HTTPS 리스너를 추가하면 자동으로 Secure listener settings가 생기면서 위의 Certificate Manager에서 생성한 인증서를 선택할 수 있게 돼요.(타깃그룹 생성은 Basic configuration에서 Instances를 지정, 이름 지정, 프로토콜은 HTTP/포트는 80, 나머지는 디폴트로 선택, 다음으로 넘어가 Available instances에서 인스턴스를 선택하고, include as pending below를 클릭하여 아래 Review Targets에 추가되도록 함)
네임서버에서 A레코드에 로드발란서 지정
이렇게 인증서가 정의된 로드 발란서가 만들어졌으면, 외부 트래픽이 해당 로드 발란서를 통해 인스턴스에 전달될 수 있도록 해줄 필요가 있어요. 저 같은 경우, 이전에는 도메인 구매처에서 제공하는 네임서버를 사용했었는데요. 이제는 IP가 아니라 로드 발란서를 지정할 수 있어야 하므로, 아마존의 Amazon Route 53이라는 DNS 웹서비스를 사용합니다. 도메인 하나 당 월 0.5달러의 요금이 부과되니 참고하시고요. 그러기 위해서 도메인 관리 사이트(저는 호스팅 케이알에서 구매했음)에 아마존으로 name server를 지정해주고(그때 자동적으로 이전의 DNS레코드들은 모두 사라짐), Route 53에서 DNS 레코드를 관리하도록 이전 작업을 수행했어요. 모두 그대로 옮기면 되고, A레코드의 경우만 트래픽 라우팅 대상에 별칭을 선택한 후 준비한 로드밸런서를 선택해주면 됩니다.
이 작업으로 모든게 끝났어요. 이제 여러분도 크롬의 주소창 앞에 자물쇠 모양을 볼 수 있게 되었습니다!
