오늘 포스팅은 이전 포스팅 주제였던 ACG(Access Control Group)에 이어 서버 내부 방화벽, 그 중에서도 GEOIP에 대해서 작성해보려합니다.
글로벌 사이버테러는 지속적으로 늘어나고 있고 공격 유형도 다양해지고 있습니다.
ACG는 Inbound Rule이 기본 차단이고 추가하는 IP/ACG에 대해서 허용하는 방식입니다. 또한 NACL을 이용한다고 하여도 한 국가가 사용하는 IP 대역을 전부 허용/차단 룰을 추가해주는 것도 힘들 것입니다.
주로 웹 서비스가 대표적인 케이스인데 해외 서비스를 하지 않는 경우 또는 특정 국가에서 서비스를 해야하는데 지속적인 공격으로 지역 기반 차단이 필요한 경우가 있습니다.
물론 Naver Cloud Platform의 Security Monitoring 서비스를 사용한다면 IDS/IPS, WAF, Anti-DDOS 등을 사용할 수 있으나 아직 보안 장비에 투자할 비용이 부족한 사용자에게는 부담스러울 수가 있어 비록 100% 완벽하지 않으나 어느정도 피해를 최소화하기 위해 GeoIP 모듈을 이용하여 내부 방화벽으로 서버를 지역 기반 차단하는 방법을 작성해보겠습니다.
Linux
iptables
Linux에서 지역 기반 차단을 진행해봅시다. 방화벽은 모두가 아는 iptables를 사용할 것입니다.
(좌) kernel-devel 정상 설치되지 않음 / (우) kernel-devel 정상 설치 완료
kernel-devel이 정상적으로 설치되지 않으면 이후 설치할 xtables 컴파일이 정상적으로 되지않습니다. yum으로 현재 커널 버전에 맞는 kernel-devel이 설치되지 않을 경우 repo를 찾아 커널 버전에 devel을 설치해주어야합니다.
※ xtables 설치 ?
[root@manvscloud-dev-pub-kr1 ~]# cd /usr/local/src
[root@manvscloud-dev-pub-kr1 src]# wget mirror.koreaidc.com/iptables/xtables-addons-2.10.tar.gz
// https://sourceforge.net/projects/xtables-addons/files/Xtables-addons/ ← 접속 시 각 버전별 xtables가 있습니다.
[root@manvscloud-dev-pub-kr1 src]# tar xvfz xtables-addons-2.10.tar.gz
[root@manvscloud-dev-pub-kr1 src]# cd xtables-addons-2.10/
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# cat -n mconfig | grep TARPIT
12 build_TARPIT=m
// build_TRIPIT=m은 redhat에서 지원하지않아 주석처리 해주었습니다.
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# sed -i '12s/build_TARPIT=m/#&/' mconfig
(참고로 CentOS6 버전 이용 시 커널 버전이 낮아 xtables 버전 역시 낮춰서 설치하셔야합니다. 1.37버전 설치 권장드리며 mconfig에서 build_RAWNAT=m, build_SYSRQ=m, build_TARPIT=m, build_length2=m 총 4가지를 주석처리 해줘야합니다.)
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# ./configure
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# make
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# make install
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# cd geoip
[root@manvscloud-dev-pub-kr1 geoip]# ./00_download_geolite2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: geolite.maxmind.com; Unknown error
00_download_geolite2를 실행해도 되지않기때문에 따로 GeoLite2-Country-CSV를 받아야합니다.
https://maxmind.com/ 에 가입 후 라이센스 발급 및 GeoLite2-Country-CSV.zip 설치가 가능합니다.
// 아래 MaxMind 링크를 추가해두었습니다.
[root@manvscloud-dev-pub-kr1 geoip]# ll | grep GeoLite2
-rw-r--r-- 1 root root 1934768 May 29 08:25 GeoLite2-Country-CSV_20210525.zip
[root@manvscloud-dev-pub-kr1 geoip]# ./10_download_countryinfo
[root@manvscloud-dev-pub-kr1 geoip]# unzip GeoLite2-Country-CSV_20210525.zip
[root@manvscloud-dev-pub-kr1 geoip]# perl -MCPAN -e shell
cpan[1]> install NetAddr::IP
cpan[2]> install Getopt::Long
cpan[3]> quit
[root@manvscloud-dev-pub-kr1 geoip]# cat GeoLite2-Country-CSV_20210525/GeoLite2-Country-Blocks-IPv{4,6}.csv | ./20_convert_geolite2 /tmp/CountryInfo.txt > GeoIP-legacy.csv
[root@manvscloud-dev-pub-kr1 geoip]# ./xt_geoip_build GeoIP-legacy.csv
[root@manvscloud-dev-pub-kr1 geoip]# mkdir -p /usr/share/xt_geoip
[root@manvscloud-dev-pub-kr1 geoip]# cp -a {BE,LE} /usr/share/xt_geoip/
[root@manvscloud-dev-pub-kr1 geoip]# cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables_org
[root@manvscloud-dev-pub-kr1 ~]# systemctl enable iptables
[root@manvscloud-dev-pub-kr1 ~]# systemctl start iptables
/etc/sysconfig/iptables 수정하여 룰셋 적용해서 사용하시면 됩니다.
Login | MaxMind
This page requires a login.
TIP & Personal Comments and Wrap-up
windows firewall
Windows에서 역시 국가 기반 차단이 가능합니다.
Powershell을 이용한 방화벽 컨트롤 및 IPSec 설정의 방법이 존재하는데 이번 편에서는 따로 다루지 않고 IPsec 편에서 추가적으로 설명하도록 하겠습니다.
또한 Apache와 Nginx 등 소프트웨어단에서 국가 기반 차단을 할 수도 있습니다. 이후 이러한 소프트웨어단에서 국가 기반 차단을 하는 방법도 포스팅할 것입니다.
KISA WHOIS
국가 인터넷주소관리기관인 한국인터넷진흥원은 안정적인 인터넷주소관리로 세계 최고의 인터넷 환경을 만들어 갑니다.
위 링크는 WHOIS입니다. 서버내에서 공격성 접근 확인 시 해당 IP를 위 사이트에서 검색할 경우 어느 나라의 IP인지 확인이 가능합니다.
국가코드 조회
국가명/코드명
국가 기반 차단 시 필요한 국가 코드 및 WHOIS 조회 시 국가코드가 어느 나라인지 확인할 수 있는 국가 코드 조회 사이트도 참고하시면 좋을듯합니다.
“1-1~1-2. [NCP] 네이버 클라우드에서의 보안 – Account 편” 포스팅이 끝나고 “2. [NCP] 네이버 클라우드에서의 보안 – Server 편” 포스팅을 작성하게 되었습니다.
오늘은 네이버 클라우드에서 Server 보안의 첫 번째 ACG(Access Control Group)를 알아봅시다. ACG는 IP/Port 기반 네트워크 접근 제어 및 관리를 할 수 있는 무료 방화벽 서비스입니다. Console에서 쉽게 허용된 트래픽만 접근할 수 있도록 설정하여 외부의 침입으로부터 차단해주는데 간단하고 단순하지만 잘 사용한다면 견고한 보안을 보여줄 것입니다.
ACG (Access Control Group)
https://www.ncloud.com/product/networking/vpc
네이버 클라우드에서 ACG는 Classic 환경과 VPC 환경에 조금 차이가 있습니다. 간단하게 표로 만들어보았으니 그림을 통해 차이를 확인해보시기 바랍니다.
Classic – ACGVPC – ACG
ACG에서는 TCP, UDP, ICMP 프로토콜에 대해 규칙 설정이 가능하며 192.168.0.1(단일), 10.0.1.0/24(대역), 0.0.0.0/0(전체), manvscloud-acg(ACG 이름) 으로 접근소스 지정이 가능합니다. (manvscloud.com과 같이 도메인은 불가능)
(좌) Classic ACG / (우) VPC ACG 차이가 있습니다.
VPC 환경에서는 Inbound / Outbound 규칙을 설정할 수 있으며 기본적으로 Inbound는 차단, Outbound는 허용입니다. (Classic은 X)
Inbound 규칙 : 서버로 들어오는 트래픽(외부→내부)에 대한 규칙
Outbound 규칙 : 서버에서 나가는 트래픽(내부→외부)에 대한 규칙
How to use ACG well
ACG를 어떻게 잘 사용할까요?
VPC 환경을 기준으로 아래와 같이 서버를 생성하여 보여드리겠습니다.
예시로 bastion host 1대, web server 1대, db server 1대를 생성하였습니다. Bastion host에 대한 ACG는 정말 접속이 필요한 사용자만 접근할 수 있도록 허용하는 방법을 사용하고 추가적인 접근 통제는 VPN 또는 서버 내부에서 사용자 계정을 생성하여 계정 관리 및 탐지를 합니다.
Web Server는 ACG를 어떻게 주면 좋을까요? Web Server로 SSH 접근하는 IP를 추가해주어야 할 것이고 HTTP, HTTPS 포트도 열어주어야할 것입니다. 저는 ACG 하나에 몰아서 넣기보다 분리해서 사용하며 ACG 생성 시 네이밍도 이후 잘 구분할 수 있도록 만드는 편입니다. (프로젝트명-용도-acg)
manvscloud-admin-acg에는 관리자 접속용 acg입니다. manvscloud 프로젝트 전체에 접속이 필요한 관리자들에 대한 정책을 추가하여 사용합니다. 동일한 프로젝트의 다른 서버 생성 시에도 해당 acg만 추가해주기만 하면 되어 관리하기도 좋습니다. 또한 manvscloud-web-acg는 manvscloud 프로젝트의 web서버에 대한 acg입니다. web서버마다 동일하게 필요한 정책을 추가하여 관리합니다. 이후 추가되는 web 서버마다 acg를 추가 생성하지 않고 해당 acg를 추가하여 공통으로 사용합니다. 마지막 하나의 acg는 위 사진에는 추가되어 있지않지만 필요 시에 해당 서버에만 특정적으로 필요로하는 서비스 해당 서버에서만 open되어야하는 정책에대한 acg를 추가하여 관리합니다. (예를 들면 개발자가 특정 웹 서버 FTP 접근이 필요할 경우)
정리하면 제가 ACG를 관리하는 방식은 아래와 같습니다.
admin-acg (프로젝트 공통 관리자 관리 정책 ACG)
web-acg, mysql-acg, was-acg 등 (공통 서비스 관리 정책 ACG)
*-acg (특정 서버에만 적용되어야하는 정책 ACG)
더 좋은 ACG 사용 방법이 있다면 댓글로 의견 부탁드립니다.
위 정책은 웹 서버에 대한 web-acg 입니다. 제가 80포트를 0.0.0.0/0이 아니라 왜 10.0.13.0/24와 10.0.33.0/24 으로 열어두었을까요?
이유는 바로 제가 LB와 연결을 해놓았기때문입니다. 많은 고객분들이 웹 서버와 LB를 함께 사용하십니다.
만약 0.0.0.0/0으로 열어두었다면 도메인-LB-웹서버로 통신되는 것 외에도 웹서버 IP를 통해 웹서버로 접근 역시 가능합니다. 물론 웹서버 내에서 IP주소로 접근이 불가능하도록 설정이 가능하지만 방화벽 룰셋은 굳이 접근이 필요하지 않은 부분까지 허용하는 것은 권장하지 않으며 좋은 습관이 아닙니다.
위 ACG와 같이 설정하게되면 LB로는 접속 가능하지만 웹서버 IP로는 다이렉트로 접속이 불가능하게 됩니다.
이제 예시 중 DB Server에 대한 ACG 관리를 보겠습니다.
DB 서버는 주로 bastion host와 DB 연동이 필요한 서버에 대한 허용 정책을 설정하게되는데 아래와같이 ACG 이름을 이용하여 설정할 수 있습니다.
bastion-host Server와 연결된 manvscloud-bastion-acg를 DB Server ACG에 접근 포트 허용을 해주게된다면 manvscloud-bastion-acg와 연결된 서버들은 DB Server로 접근을 할 수 있게되는 것입니다.
추가 예시로 Web Server 전체가 DB와 연결되어야할 경우 ACG를 넣어줄 수 있으며 “나는 모든 웹 서버와 모든 DB 서버가 연결되지 않아 보안상 따로 따로 지정을 해줘야한다”라고 한다면 특정 서버에만 적용되어야하는 정책 ACG를 추가하여 연결되어야할 서버 IP만 허용해주는 방법이 있습니다.
Personal Comments and Wrap-up
지금까지 쉽고 간단한 ACG(Access Control Group)에 대해 알아보았습니다. 많은 사용자들이 귀차니즘으로 인해 ACG 관리가 잘 되지않고 있습니다. 원격 접속 포트, 쉘 접근 포트 등 중요한 포트를 0.0.0.0/0(전체)로 열어두는 사용자들을 생각보다 많이보게되고 또 보안상 위험을 알려도 아무 일 없을 거라며 넘어가버리는 분들 역시 많았습니다. (귀찮아서 내버려뒀을 때 편한 감정과 공격받아 데이터 손실 후 감정은 많이 다릅니다…)
제발 막아주세요?
다음 포스팅은 “2-1. [NCP] 네이버 클라우드에서의 보안 – SERVER”에 이어 “2-2. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT” 내용은 IPSec VPN과 SSL VPN에 대해서 작성하려고 했었는데 ACG에 대한 내용에 이어 서버 내부 방화벽 활용 방법을 먼저 포스팅하려고 합니다.
이전 포스팅 “1-1. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT”에 이어 “1-2. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT” 포스팅입니다. API 인증키와 Sub Account에 대한 내용으로 오늘도 중요한 계정 보안에 해당되는 내용입니다.
Manage API authentication keys
API 인증키는 Server, Load Balancer, Auto Scaling, Monitoring, Security 등 다양한 기능을 API로 제어가 가능합니다. Access Key를 통해 여러 기능을 API로 제어할 수 있다보니 Key가 유출될 경우 해커가 리소스 등록, 수정, 조회를 자유롭게 할 수 있게되므로 Key를 주기적으로 변경해주어야 겠습니다.
메인 계정의 경우 마이페이지 → 인증키 관리에서 확인할 수 있습니다. (Sub Account의 API Key도 관리해줍시다. (개인 Sub Account → API Key))
메인 계정의 경우 모든 권한을 갖는 Root, Administrator 같은 계정이라고 볼 수 있습니다. 메인 계정의 API key가 유출될 경우 상당히 크리티컬한 문제로 이어질 수 있기에 Sub Account을 이용하여 API Key를 사용하는 것이 좋겠습니다.
(Access Key와 Secret Key를 GitHub 같은 곳에 떡하니 올려놓는 일은 발생하지 않길바랍니다…)
API에 대한 설명은 가이드가 잘 되어있어 링크로 추가하였으니 참고하면 좋을듯 합니다.
NAVER Cloud Platform API – API 가이드
네이버 클라우드 플랫폼에서 제공하는 인프라/솔루션 상품을 이용할 수 있도록 지원하는 응용 프로그램 인터페이스(Application Programming Interface, API) 제공하고 있습니다.
본 페이지에서는 NAVER Cloud Platform API 대한 간략한 설명 및 API 호출하는 방법을 제공합니다.
API는 RESTful API 방식으로 제공되며, XML와 JSON 형식으로 응답합니다. 액션에 따라 파라미터 값을 입력하고 등록, 수정, 삭제, 조회할 수 있으며, 서비스 및 운영 도구 자동화에 활용할 수 있습니다. …
SubAccount
보안 위험으로부터 관리하려면 적절한 통제가 필요합니다. [Management] 카테고리에 있는 SubAccount를 이용한다면 RBAC(Role-Based Access Control) 즉 역할 기반 접근 통제가 가능합니다.
이 서비스를 이용하여 직무 분리를하고 최소 권한을 줄 것입니다.
* 직무 분리 : 권한 오남용이나 고의적 행위로 인해 발생할 수 있는 잠재적 피해를 줄이기 위해 필요하며 불가피한 이유로 직무 분리가 어려운 경우 별도의 보완 통제가 필요합니다. * 직무 분리 및 책임 및 최소 권한의 원칙, 직원 보안, 알 필요성의 원칙, 직무 순환, 신의 성실의 원칙이 관리적 통제에 속하며 기술적, 물리적 통제도 존재합니다.
[웨비나] 클라우드 보안 A to Z: 클라우드상 책임 공유 모델 IAM 이해하기에서 나왔던 부분을 간단하게 소개하고 영상 링크를 아래에 추가해두었습니다. 내용이 좋으니 영상을 보시면 이해에 많은 도움될 것입니다.
[Main Account] Main Account는 Naver Cloud Platform에 가입하게 될 때 사용한 이메일 주소입니다. Main Account를 통해서만 Sub Account의 사용자를 생성할 수 있으며 테넌트가 독립적으로 접근 가능한 콘솔 도메인을 생성할 수 있습니다. Naver Cloud Platform 전체 리소스를 관리합니다.
* 테넌트 : 소프트웨어 인스턴스에 대해 공통이 되는 특정 접근 권한을 공유하는 사용자
[Sub Account] RBAC(Role-Based Access Control) 기능을 통한 권한 관리를 Sub Account를 통해 구현합니다. 주요 직무자를 식별할 수 있도록 naming 규칙을 통해 이용자를 생성하고, 권한을 부여하여 관리할 수 있습니다.
[Group] 동일한 역할을 수행하는 이용자를 그룹화하여 관리합니다.
[Policies] Policies를 통해 Sub Accounts와 Group에 권한을 부여할 수 있습니다.
위 서비스를 이용하여 아래와 사진과 같이 직무 분리하여 사용할 수 있습니다.
[Main Account Role] Sub Account 사용자 생성 Sub Account 사용자 권한 부여/회수 Sub Account 장기간 미 접속 계정 관리 미사용 리소스에 대한 관리 제거 삭제
[Security Manager Role] Sub Account 사용자 권한 부여 검토 사용자/리소스의 생성/삭제/변경의 적정성 검토 보안 서비스의 적용/운영
[Infra Manager Role] VPC/Server의 생성, 운영 및 변경 관리 ACG/NACL등의 허용/차단 관리
[DB Manager Role] DB의 생성, 운영 및 변경 관리
[웨비나] 클라우드 보안 A to Z: 클라우드상 책임 공유 모델 IAM 이해하기
#네이버클라우드플랫폼 #네이버클라우드#클라우드보안 #보안 #책임공유모델 #IAM클라우드 보안 관련 웨비나 영상입니다.[목차]00:00 목차 소개00:47 Overview02:40 NAVER CLOUD PLATFORM Security05:51 Security Center06:17 S…
추가로 위 영상을 보면 좋을듯하나 영상을 볼 시간이 없으신 분들을 위해 각 리소스 별 네이밍 방법을 아래에 추가했습니다.
리소스 별 네이밍을 잘 해두는 것도 상당히 중요합니다. 저는 네이밍을 설정할 때 아래표와 같이 설정하지는 않지만 나름 규칙적이고 리소스를 찾을 때 구분이 쉽도록 설정해두는 편입니다.
예를 들어 서버를 하나 생성 시 manvscloud-web-prd-kr1와 같이 만드는 것이죠. 어떤 프로젝트인지, 어떤 서비스를 하는 서버인지, 개발/운영, 리전을 나누어 네이밍합니다. 리소스 이름 길이가 제한이 있어 프로젝트 이름을 mvsc와같이 축약하는 방법도 있습니다.
각자만의 방법으로 네이밍을 하더라도 리소스 이름만 봐도 확실히 구분된다면 좋은 네이밍이라 볼 수 있습니다.
Sub Account – Training
생성 실습을 보며 Sub Account를 어떻게 사용할지 고려해보시기 바랍니다.
1. Sub Account가 접속할 수 있는 Link 생성
접속 페이지 설정을 해주면 해당 페이지로 Sub 계정들이 접근이 가능합니다패스워드 만료도 설정할 수 있습니다.
2. 위에서 생성한 도메인으로 접속할 Sub Account 생성
이제 Sub Account를 만들어보도록 하겠습니다.각 정보들을 입력해줍니다.
접근 유형을 Consle 접근, API 접근 선택해줍니다. Console 접근 설정 시 모든 곳에서 접근 가능 및 지정한 IP 대역에서만 접속 가능 여부를 설정할 수 있습니다.
저는 지정한 IP에서만 접근 가능도록 설정하는 것을 적극적으로 권장드립니다. IP 지정 이후 [서브 계정 상세]에서 접근 가능 IP대역 조회/변경/추가/삭제가 가능합니다.
또한 강력한 권한을 가진 계정일수록 2차 인증 설정 역시 권장합니다.
로그인 비밀번호를 설정한 뒤 생성합니다.
Main 계정에서 Sub 계정들을 사진과 같이 관리할 수 있습니다. 일시 정지 및 일시 정지 해지 등이 관리 가능하니 더 이상 사용하지 않는 계정은 방치해두지 말고 삭제해야하며 일시적으로 사용하지 않는 경우 일시 정지하여 계정 사용이 필요 시에만 사용할 수 있도록 운영해야합니다.
3. 정책(Policies) 설정
정책 설정은 이미 만들어진 관리형 정책이 있으며 정책을 생성하여 커스터마이징이 가능합니다.
정책 설정 시 VPC/Classic별로 설정이 가능하며 제품별 정책이 설정가능합니다. 리소스를 지정하여 선택된 리소스에 해당해서만 정책이 적용되도록 설정할 수 있고 전체 선택 후 따로 리소스 지정 여부 선택없이 적용대상을 추가하면 모든 리소스를 대상으로 추가가 됩니다.
전체 리전, 모든 리소스 모든 Server 권한
지금 실습으로 보여지는 정책을 따라하기보다 실무에서는 요구되는 보안사항에 따라 정책을 설정하여 직무 분리 및 최소 권한의 원칙을 지킵시다.
4. 그룹(Groups) 생성
그룹 이름 설정 후 생성
그룹에는 생성한 서브 계정과 정책을 추가하여 관리가 가능합니다. web_prd_engieer라는 그룹에 엔지니어 5명의 서브 계정을 생성 및 추가 해주고 해당 그룹이 공통적으로 가져야할 정책을 추가해주면 되겠습니다. (그룹 하나에 서브 계정 하나로 여러 엔지니어가 함께 사용한다면 책임추적성X)
5. 역할(Roles) 생성
이후 Server 뿐만 아니라 다른 리소스도 추가될 예정입니다.
역할에 속한 Server는 자격 증명을 위한 Key를 서버 내 저장하지 않아도 역할을 통해 Naver Cloud 내에 서비스 및 리소스 접근이 가능합니다. (서버 내 Key 저장을 하지 않아도 되기에 보안 위험에 도움됩니다)
해당 Role에 필요한 정책과 Role을 소유할 리소스를 선택해줍니다.
지금까지 Sub Account를 이용한 역할 기반 접근 통제에 대해 알아보고 실습도 해보았습니다. RBAC에 대해 깊이있게 공부하다가 읽어보게된 PDF 파일이 하나 있는데 내용이 좋아서 해당 링크를 아래에 추가 했습니다.
서비스 기반 RBAC의 효율적인 개인별 정책 설계에 관한 연구
기업이나 기관에는 법률과 지침에 근거하여 개인정보 보호를 위한 정책이 수립한다. 하지만 개인별로 정보 유출시 침해정도가 다름에도 기관은 개인정보의 특수성을 고려되지 않은 상태로 접근제어가 이루지고 있다. 개인정 보의 특수성을 고려하여 개인이 자신의 정보를 보호하기 위한 정책을 수립할 필요하다
Personal Comments and Wrap-up
Security-ManVSCloud
보안학과 졸업 후 정말 오랜만에 보안에 대해서 생각해보는 시간을 갖고 포스팅을 하고 있습니다.
보안학을 배울 때도 자주 들었던 말이지만 취업을 하고 꽤 긴 시간동안 일을 해오면서도 “100% 완벽한 보안은 없다.” 라는 말은 정말 맞는 말이구나 자주 느낍니다. 보안을 따로 배우지 않았음에도 오랜 기간 IT업계에서 일을 하신 분들이라면 다들 공감하실 것입니다. 그리고 무엇보다 피해최소화가 중요하다는 걸…
아마 다음 포스팅은 “[NCP] 네이버 클라우드에서의 보안 – Server”가 예정되어 있습니다. 내용이 길어질 경우 나누어 포스팅 될 수 있으니 참고 부탁드리며 [NCP] 네이버 클라우드에서의 보안 시리즈 사이 다른 포스팅도 작성됩니다.
긴 글 읽어주셔서 감사합니다.
0. [NCP] 네이버 클라우드에서의 보안 – INTRODUCE
안녕하세요. ManVSCloud 김수현입니다.
오늘은 국내 클라우드 Naver Cloud Platform에서의 보안을 간단히 소개해보는 포스팅을 작성해보려합니다.
1-1. [NCP] 네이버 클라우드에서의 보안 – Account
안녕하세요. ManVSCloud 김수현입니다.
이전 “[NCP] 네이버 클라우드에서의 보안 – INTRODUCE” 포스팅에 이어 계정 보안을 어떻게 하면 좋을까?에 대한 고찰을 목적으로 작성하게 되었습니다.
이전 “[NCP] 네이버 클라우드에서의 보안 – INTRODUCE” 포스팅에 이어 계정 보안을 어떻게 하면 좋을까?에 대한 고찰을 목적으로 작성하게 되었습니다.
“[NCP] 네이버 클라우드에서의 보안 – ACCOUNT”에서는 계정을 어떻게 안전하게 사용할까?의 내용이 주목적이며 내용이 다소 길어져 1-1, 1-2로 나뉘어 포스팅 됩니다. 계정 보안에 앞서 클라우드 보안 인식에 대해 먼저 알아보도록 하겠습니다.
Cloud Security
클라우드 보안, 다들 어떻게 생각하시나요?
많은 사람들이 클라우드는 보안상 취약하다고 생각합니다. 클라우드 역시 온프레미스와 동일하게 네트워크 보안, 서버 보안 등 다양한 보안 서비스가 존재합니다. 네이버 클라우드를 예로 살펴보면 아래 그림과 같이 기존 온프레미스에서 사용하던 IDS/IPS, 방화벽, 웹 방화벽, DB암호화 등 모두 서비스로 준비되어있습니다. 이는 네이버 클라우드뿐만 아니라 AWS나 Azure,GCP 등도 동일합니다.
[새 탭에서 이미지 열기]를 하면 큰 화면으로 볼 수 있습니다.
클라우드라고 해서 보안상 더 취약하다고 볼 수는 없는 것입니다. 또한 고객 책임 영역을 파악하고 사용하는 리소스의 책임 영역에 대해서 철저히 관리하면 됩니다.
직접 서버를 IDC에 보관할 경우 랙, 케이지, 온도, 즉 하드웨어나 시설은 고객 책임 영역에서 네이버 클라우드 플랫폼 책임 영역이 됩니다. 단 콘솔 페이지로 로그인 할 계정을 잘 관리 해야합니다.
고객의 입장에서는 클라우드가 온프레미스보다 보안상 취약하다라고 보기보다 클라우드와 온프레미스가 고려해야할 보안 사항에 차이가 있다라고 보는 게 맞다고 봅니다.
CSO에 따르면 클라우드 보안에 주요 위협이 되는 것은 약 11가지가 존재한다고 합니다.
11 top cloud security threats
More data and applications are moving to the cloud, which creates unique infosecurity challenges. Here are the “Egregious 11,” the top security threats organizations face when using cloud services.
* CSO : 원래 Chief Security Officer (최고 보안 책임자)의 약자이며, 여기서 언급한 CSO는 비즈니스 연속성 및 데이터 보호에 대한 최신 정보와 모범 사례, 사회 공학 사기 예방 모범 사례 등을 제공하는 산업 보안 및 정보보호 관련 사이트입니다.
주관적으로 나머지 보안을 아무리 열심히 준비했더라도 메인 계정에 문제가 생긴다면 막대한 피해를 입게되기에 저는 Account hijacking을 가장 먼저 다루어야할 핵심으로 봅니다.
계정이 공격자에 의해 도용/탈취를 당하게 된다면 어떤 영향들을 미치게 될까요? 해커의 악의적인 행동으로 인하여 데이터 유출이나 조작으로 막대한 피해로 이어질 수 있기에 계정 도용/탈취는 매우 치명적이라고 볼 수 있는데요.
해커가 계정을 도용/탈취할 수 있는 방법 중 대표적인 예로는 무차별 대입 공격(Brute-force), 사전 공격(Dictionary Attack), XSS (Cross-Site Scripting) 공격, 버퍼 오버플로우(BufferOverflow), 키로거(Keylogger), 피싱(Phishing)이 존재합니다.
* 무차별 대입 공격(Brute-force) : 공격자가 성공할 때까지 암호를 추측(모든 가능한 문자를 조합)하여 계정에 액세스 * 사전 공격(Dictionary Attack) : 자주 사용하는 단어나 문장, 생일 등을 만들어두고 이를 대입하는 공격 * XSS (Cross-Site Scripting) : 공격자가 웹 브라우저를 통해 악성 스크립트를 전송하여 취약한 계정에 액세스하는 인젝션 공격 유형 * 버퍼 오버플로우(BufferOverflow) : 공격자에게 무단 액세스를 제공하도록 설계된 악성 데이터로 메모리의 데이터 덮어 쓰기 * 키로거(Keylogger) : 사용자 ID 및 비밀번호를 포함하여 사용자가 입력한 키를 기록하고 공격자에게 정보를 보내는 프로그램 * 피싱(Phishing) : 정보를 훔치거나 세션 ID를 도용하기 위해 사용자를 보안되지 않은 웹 사이트로 유도
오늘은 이러한 위협들 속에서 우리 계정을 어떻게 보호할 수 있을까에 대해 자세히 알아보도록 하겠습니다.
Password
우리가 Naver Cloud를 이용하기 위해서 가장 먼저 해야하는 것은 먼저 해당 페이지에서 로그인을 해야하는 것입니다. (네이버 클라우드 뿐만 아니라 AWS,Azure,GCP 등 모두 해당)
그 외에 Shell, 원격 접속을 할 때도 계정, 패스워드를 입력하여 접근을 합니다. 패스워드 관리에 대한 부분은 콘솔 로그인 뿐만 아니라 서버 계정 관리에도 도움되도록 작성 해보려합니다.
PASSWORD란 본인 확인을 위한 요소 중 하나인데 누군가 나의 ID와 PASSWORD를 쉽게 알 수 있다면 나의 계정은 보안이 매우 취약한 것입니다. 이 패스워드를 어떻게 관리하면 좋을까요?
가장 먼저 우리가 생각해보아야 하는 것은 패스워드 길이와 복잡성이라 말할 수 있습니다. 비 인가자로부터 brute-force, Dictionary attack 공격을 받을 경우 암호의 길이와 복잡성에 따라 해커가 암호를 알아내기까지 소요 시간은 상당한 차이가 있는데 암호의 길이가 짧고 복잡성이 떨어질 경우 얼마나 빠른 시간 내에 암호 탈취가 가능한지 테스트하는 것도 보여드리겠습니다.
※ 패스워드는 이렇게 관리하자 ?
패스워드 길이 최소 8자 이상 (영문자 대문자+소문자+ 숫자+특수문자를 조합)
무작위 비밀번호 생성기 – 보안 비밀번호를 손쉽게 생성
인터넷을 통해 전송되지 않으면서 브라우저에서 강력한 비밀번호를 손쉽게 생성하고 일반적인 방식에 의한 해킹을 예방하는 10가지 방법에 대해서도 배울 수 있습니다.
새 사용자 최초 로그인 시 새로운 패스워드로 변경하도록 적용 (Sub Account 생성 시 생성된 서브 계정 로그인 시 비밀번호 재설정 체크)
(Linux의 경우 “chage -d 0 계정명” 명령어를 사용해주면 해당 사용자가 로그인 시 새로운 패스워드로 설정할 수 있게 됩니다.)
로그인 시도에 대한 정보를 볼 수 있는 감사 기록 (Cloud Activity Tracer를 이용하면 Naver Cloud 계정 로그인 감사 기록을 확인할 수 있습니다.)
실패한 로그인 시도 횟수를 제한하는 임계치를 설정(Clipping Level)
마지막으로 당연한 말이지만 패스워드를 공유하지 않는 것입니다. (책임추적성 수립이 되지 않기때문인데 시스템 내의 각 개인은 유일하게 식별되어야 한다는 정보 보호 원칙입니다.)
추가로 패스워드 탈취를 위한 공격 기법은 어떤 것이 있고 이 공격들로부터 어떻게 대응해야할지 적어보겠습니다.
[패스워드 공격 기법] ▶ 무차별 대입 공격 (Brute-force) ▶ 사전 공격 (Dictionary Attack) ▶ 사회 공학 (어깨 넘어로 훔쳐보거나 권한 가진 사용자 따라다니는 행동, 협박, 공갈, 갈취, 파쇄되지 않은 채 버려진 보안 문서, 피싱이 여기에 해당됩니다.) ▶ 패스워드 파일에 대한 접근 ▶ 전자적 모니터링 (패스워드 입력 혹은 전송 시 스니핑으로 패스워드가 모니터링 됨) ▶ 트로이 목마(로그인 프로그램)
[대응책] ▶주기적인 패스워드 변경 ▶패스워드 재사용 제한, 패스워드 파일 저장 시 단방향 암호화 사용 (단방향 암호화는 복호화가 불가능해 암호화된 비밀번호가 유출돼도 암호를 알아낼 수 없음) ▶로그인 실패 횟수 제한 : Clipping Level 설정, Internet 3 Strike-out
▶취약한 패스워드를 찾아내기 위한 감사 툴 사용 ▶사전 공격 및 무차별 공격을 탐지하기 위한 IDS 사용
※ John the Ripper ⚔
마지막으로 John the Ripper를 이용하여 패스워드 탈취 테스트를 해보겠습니다.
John the Ripper는 많이 알려져있는 패스워드 크랙 툴입니다. dictionary attack과 brute-force로부터의 테스트를 할 수 있습니다.
[root@manvscloud-security-kr1 ~]# useradd user
[root@manvscloud-security-kr1 ~]# useradd admin
[root@manvscloud-security-kr1 ~]# passwd user
[root@manvscloud-security-kr1 ~]# passwd admin
우선 테스트에 사용될 계정 및 패스워드 생성을 해주었습니다. user 의 계정에는 123456 이라는 패스워드를 주었고, admin 계정에는 apple이라는 패스워드를 주었습니다.
이제 John the Ripper를 설치해봅시다.
John the Ripper password cracker
A fast password cracker for Unix, macOS, Windows, DOS, BeOS, and OpenVMS
[root@manvscloud-security-kr1 ~]# cd /usr/local/src
[root@manvscloud-security-kr1 src]# wget https://www.openwall.com/john/k/john-1.9.0.tar.gz
[root@manvscloud-security-kr1 src]# tar zxvf john-1.9.0.tar.gz
[root@manvscloud-security-kr1 src]# cd john-1.9.0/src
[root@manvscloud-security-kr1 src]# make
여기서 make를 하면 make할 리스트가 나옵니다. system에 맞는 것을 선택하여 make 해줍시다.
[root@manvscloud-security-kr1 src]# arch
x86_64
[root@manvscloud-security-kr1 src]# make linux-x86-64
[root@manvscloud-security-kr1 src]# cd ../run
[root@manvscloud-security-kr1 run]# ./john 입력 시 옵션 설명을 추가로 볼 수 있습니다.
// 위에서 생성한 계정에 대한 shadow 파일 내용을 따로 txt 파일로 빼줬습니다.
[root@manvscloud-security-kr1 run]# cat /etc/shadow | tail -n 2 > shadow.txt
// 암호화된 것을 알 수 있는데 이제 이 암호화된 내용을 크랙하겠습니다.
[root@manvscloud-security-kr1 run]# cat shadow.txt
user:$6$6NkXOEsJ$N316O3215K8hN4Hblj6Fk5QSpjvyjRCtt93iIzivV8eGPp.8qZXtrpUOhX93nSrUN.hagw3Toyux24epDZHOv0:18765:90:120:30:::
admin:$6$lXYhYqgH$/I5lJOYFGLyXecWM9DCezPjLoTdSGlmzf.2Ghr8l0cCDa8LyniimBO8W2AAGuVjbcyZETG7d9iFgnkWnISa8s.:18765:90:120:30:::
//두 패스워드를 알아내는데에 21초밖에 걸리지 않았습니다.
[root@manvscloud-security-kr1 run]# ./john shadow.txt
Loaded 2 password hashes with 2 different salts (crypt, generic crypt(3) [?/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
apple (admin)
123456 (user)
2g 0:00:00:21 100% 2/3 0.09144g/s 277.4p/s 284.9c/s 284.9C/s 123456..pepper
Use the "--show" option to display all of the cracked passwords reliably
Session completed
[root@manvscloud-security-kr1 run]# ./john --show shadow.txt
user:123456:18765:90:120:30:::
admin:apple:18765:90:120:30:::
2 password hashes cracked, 0 left
이렇게 짧은 패스워드, 숫자로만 이루어져있거나 사전적인 단어로 패스워드를 사용 시 패스워드 탈취는 순식간에 일어납니다.
패스워드 길이 최소 8자 이상 (영문자 대문자+소문자+ 숫자+특수문자를 조합)으로 패스워드 설정 후 테스트해보시면 아무리 일정 시간이 지나도 패스워드가 찾아지지 않습니다. 물론 언젠가 패스워드가 찾아질 것이기에 반드시 정기적으로 보안 점검 일정을 정해두고 패스워드를 변경해야할 필요가 있습니다.
Multi-factor authentication
네이버 클라우드에서 [마이페이지]를 보시면 계정관리 쪽에 [2차인증 관리]가 있습니다. 2차인증, 즉 Two Factor Authentication(2FA)는 계정을 보호하는 데에 아주 큰 역할을 합니다.
이런 멀티팩터 인증은 이미 우리 생활 속에서 많이 사용중입니다. 대표적인 예로 ATM기에서 현금 인출을 위해서는 첫번째로 본인의 카드가 존재해야하며 두번째로 계좌 비밀번호를 알고 있어야합니다. 여기서 카드가 소유기반 인증이 되고 계좌 비밀번호가 지식기반 인증이 됩니다. Two Factor Authentication를 사용하고 있는 것이죠.
보안 강도 : TYPE-II > TYPE-I
네이버 클라우드에서는 2차 인증을 휴대폰 번호 or 이메일 주소로 인증번호 받아 인증하는 인증번호 방식과 OTP(One-Time Password) 방식이 존재합니다.
인증번호로 설정하게 될 경우 아래 그림과 같이 휴대폰 번호/이메일주소로 인증 수단을 선택할 수 있습니다.
인증 번호 방식이 아닌 OTP를 이용하여 인증하게 될 경우 디바이스에 Google OTP앱이나 Microsoft사의 Authenticator와 같은 OTP 앱이 필요합니다.
개인적으로 Microsoft사의 Authenticator 앱을 사용합니다. (Google OTP 앱을 쓰다가 디바이스를 갤럭시에서 아이폰으로 바꿨는데 OTP가 정상적으로 넘어가지 않아서 바꿨습니다.)
OTP QR 코드 등록 후 등록된 OTP의 Number로 인증 후 확인을 누릅니다. 인증 이후 로그인 시 2차 인증을 진행해야만 로그인이 가능해집니다.
2차 인증 등록은 반드시 설정하시기 바랍니다. 매우 중요합니다.★★★★★
Personal Comments and Wrap-up
이번 [NCP] 네이버 클라우드에서의 보안 주제로 쓰는 포스팅들의 내용이 다소 클 것으로 예상됩니다. Account 하나의 주제도 내용이 너무 길어져서 2번으로 나누어 쓰게 되었습니다.
“Naver Cloud에서 계정 보안은 이렇게하면 돼!” 하고 끝내버리기엔 무엇때문에 해야하는지 모르는 경우가 많습니다. 저는 항상 모르던 서비스를 사용하거나 새로운 상품을 접할 때 Why?라고 먼저 생각합니다. 왜 이것을 써야하는지? 또 사용하게 된다면 그리고 사용하지 않는다면 어떻게 되는지 궁금증이 많은 편입니다.
무엇보다 저는 이런 의문에 답이 내려지지 않으면 잘 사용하지 않는 편입니다. 그렇기에 제가 쓰는 포스팅은 주제에 대한 내용뿐만 아니라 추가되는 내용이 상당히 많음을 미리 말씀드립니다.
대신 IT를 처음 접하거나 학생들 또는 이런 궁금증이 항상 생기는 분들에게는 많은 공부가 되리라 생각합니다.
다음 포스팅은 “1-1. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT”에 이어 “1-2. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT”로 찾아뵙겠습니다.
평소보다 더욱 길었던 글, 여기까지 읽어주셔서 정말 감사합니다.
0. [NCP] 네이버 클라우드에서의 보안 – INTRODUCE
안녕하세요. ManVSCloud 김수현입니다.
오늘은 국내 클라우드 Naver Cloud Platform에서의 보안을 간단히 소개해보는 포스팅을 작성해보려합니다.
1-2. [NCP] 네이버 클라우드에서의 보안 – Account
안녕하세요. ManVSCloud 김수현입니다.
이전 포스팅 “1-1. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT”에 이어 “1-2. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT” 포스팅입니다.
오늘은 국내 클라우드 Naver Cloud Platform에서의 보안을 간단히 소개해보는 포스팅을 작성해보려합니다.
포스트 코로나 시대, 즉 접촉없이 연결되는 언택트 시대가 Covid-19의 영향으로 예상보다 빠르게 일상생활의 트렌드를 바꾸어가고 있습니다. 온라인 교육, 화상 면접, 배달 서비스 등 시대에 맞게 비대면 서비스가 증가했으며 IT 분야 역시 이러한 변화로 인해 클라우드 서비스가 많이 사용되고 있습니다.
전통적인 온프레미스 환경에서 클라우드로 변화하거나 온프레미스와 퍼블릭 클라우드를 함께 하이브리드 클라우드로 운영하시는 사용자들이 상당히 많아졌고 공공기관이나 금융기관 역시 이러한 클라우드 서비스에 대해 고려해보게 됩니다.
NAVER CLOUD PLATFORM for public institutions
Global cloud computing services on Naver’s business platforms. Start IaaS, PaaS, SaaS free of charge
(네이버 클라우드 플랫폼 – 공공기관용)
네이버 클라우드 플랫폼 금융기관용 NAVER CLOUD PLATFORM for Financial Cloud
네이버 금융 클라우드, 금융보안원 안정성 평가 100% 충족, 글로벌 리전 및 보안기술 인증 보유
(네이버 클라우드 플랫폼 – 금융기관용)
또한 국내 데이터가 해외 클라우드 서버에 저장되는 것부터 그런 데이터들이 보안 문제로 인해 유출되는 부분들까지 많은 고민이 될 것입니다. 네이버 클라우드에서는 국내 공공기관용으로 보안수준을 강화한 클라우드 서비스를 제공하고 금융기관과 핀테크 기업의 조건에 맞는 맞춤형 서비스를 제공하여 데이터를 국내에 저장하며 맞춤형 클라우드 서비스를 사용할 수 있어 더욱 신뢰성과 안정성이 있습니다.
CSA(Cloud Security Alliance) 자료에 따르면 클라우드 환경에서의 11가지 두드러진 위협/위험 및 취약점이 아래와 같이 존재한다고 말합니다.
Data Breaches (데이터 침해)
Misconfiguration and Inadequate Change Control (잘못된 구성 및 부적절한 변경 제어)
Lack of Cloud Security Architecture and Strategy (클라우드 보안 아키텍처 및 전략 부족)
Insufficient Identity, Credential, Access and Key Management (불충분한 ID, 자격증명, 액세스 및 키 관리)
Account Hijacking (계정 하이젝킹)
Insider Threat (내부자 위협)
Insecure Interfaces and APIs (안전하지 않은 인터페이스 및 API)
Weak Control Plane (약한 컨트롤 플레인)
Metastructure and Applistructure Failures (메타 구조 및 애플리케이션 구조 오류)
Limited Cloud Usage Visibility (제한된 클라우드 사용 가시성)
Abuse and Nefarious Use of Cloud Services (클라우드 서비스의 남용 및 악의적인 사용)
위 보안 위협에 대한 자세한 내용은 아래 사이트에서 다운로드 받을 수 있으니 취약점에 대한 자세한 내용을 알고싶으신 경우 자료 참고하시면 좋을듯 합니다.
Top Threats to Cloud Computing: Egregious Eleven | CSA
The report provides organizations with an up-to-date, expert-informed understanding of cloud security concerns in order to make educated risk-management decisions regarding cloud adoption strategies. The Top Threats reports have traditionally aimed to raise awareness of threats, risks and
이런 보안 위협에 대한 대비는 앞으로 더욱 중요한 사항이 될 것으로 보입니다.
Naver Cloud – Security
네이버 클라우드를 사용하며 각 서비스들마다 어떤 보안 관리를 할 수 있을지 알아보겠습니다. 우선 네이버 클라우드 플랫폼을 사용하기 위해서는 해당 페이지로 로그인을 해야합니다.
여기서 사용하는 계정을 해킹 당한다면 상당히 크리티컬한 문제로 이어집니다. 때문에 네이버 클라우드에 접속하는 계정 보안은 아주 중요하다고 볼 수 있습니다. 두번째로 네트워크 보안입니다. VPC 플랫폼을 예로 VPC 생성 후 서비스 목적에 맞게 그리고 보안 요구 사항에 따라 네트워크를 분리 하는 것이 좋습니다. 세번째로 서버 보안입니다. 서버에 올라가는 OS의 취약점부터 해당 서버로 접근할 수 있는 접근 제한 등 각 서비스 포트별로 관리도 필요합니다.
DB 보안도 필수죠. DB의 경우 아무래도 데이터 유출이나 손실이 발생하면 상당히 곤란할 때가 많습니다. 인증, 기밀성, 무결성, 가용성을 유지하기 위해 다소 많은 고민을 해야합니다. 그 외에도 스토리지 보안과 모든 활동에 대한 감사 등 보다 안전한 서비스를 구성하기 위해서는 고려해야할 사항들이 다수 많이 존재합니다.
manvscloud – ncloud security
Compliance Guide
네이버 클라우드 플랫폼에서는 Compliance Guide가 무료로 제공됩니다.
Compliance Guide가 무엇이냐?! 서비스 설명에서는 아래와 같이 설명 하고 있습니다.
“Compliance Guide는 네이버 클라우드 플랫폼이 보유한 인증서와 관련 문서를 제공하여 고객이 보안 인증에 대응하는데 도움을 주며, 네이버 클라우드 플랫폼의 각 서비스 이용 시 어떤 통제 항목이 해결되는지, 고객이 추가로 수행하여야 하는 부분은 어떤 항목인지 등을 손쉽게 확인할 수 있도록 돕습니다.”
즉 보안 인증이나 규제에 대응에 필요한 사항을 쉽게 정리한 규정 준수 가이드입니다.
이 가이드를 통해 KISA ISMS-P 인증 심사나 PCI DSS와 같은 인증에 대한 대비를 보다 원활하게 진행할 수 있습니다.
▶ 네이버 클라우드 플랫폼의 책임이 되는 통제 규격 ▶ 고객의 책임이 되는 통제 규격 ▶ 네이버 클라우드 플랫폼과 고객의 공통 책임이 되는 통제규격
Coverage 기능에서는 책임 통제 규격에 대한 식별이 쉽도록 구분되어 있으며 명확한 구분으로 사용자가 담당해야할 부분에 대한 보안 통제를 확실히 알고 대응할 수 있습니다.
또한 Products 기능을 사용한다면 네이버 클라우드의 각각의 서비스가 지원하는 통제 규격과 적용해야 하는 통제 규격을 쉽게 알 수 있습니다.
위 사진을 보면 알 수 있다시피 상품 카테고리에서 Networking-VPC를 선택하면 VPC 제품에 대한 규격을 색깔로 구분해두어 VPC 상품은 이 부분을 지원하는구나 또는 어떤 통제 규격을 적용해야하구나를 자세히 알려줍니다.
또한 “정보시스템 관련 자산(하드웨어, 운영체제, 상용 소프트웨어, 패키지 등) 변경에 대한 절차를 수립·이행 하고 있는가?”라는 내용에 마우스 커서를 올리면 해당 내용에 대한 통제를 구현하는데 이용되는 상품, 통제를 적용해야 하는 상품, 통제를 구현하는데 이용되는 상품을 알 수 있습니다.
마무리
NAVER CLOUD PLATFORM
[6월 Intermediate] 네이버클라우드플랫폼 보안 강화 교육
■ 내용 : 네이버 클라우드 플랫폼의 보안 관련 서비스 소개 및 리포트를 통한 효과적인 방어 데모
■ 대상 : 네이버 클라우드 플랫폼 보안에 관심이 있는 누구나
■ 교육 아젠다 : 네이버 클라우드 플랫폼 보안 상품 소개 및 보안 강화
6월 18일에 “[6월 Intermediate] 네이버클라우드플랫폼 보안 강화 교육” 이라는 주제로 네이버 클라우드 플랫폼에서 교육이 진행됩니다.
현재 아쉽게도 모집은 마감된 상태라 추가적인 신청이 불가능한 상태이므로 제가 해당 교육을 듣고난 후 추가적인 후기 포스팅을 남기고 제가 포스팅하고 있는 “네이버 클라우드에서의 보안” 주제에 빠진 부분을 추가 포스팅으로 채워볼 예정입니다.
다가오는 보안 교육 전에 먼저 “[NCP] 네이버 클라우드에서의 보안”이라는 주제로 포스팅을 진행하게 될 것이며 다음 포스팅은 앞서 간단히 소개된 계정, 네트워크, 서버, 데이터베이스, 스토리지, 감사, 이중화, 백업 등에서의 보안을 하나씩 자세히 다루어보는 내용으로 나누어 포스팅 됩니다.
이제는 클라우드, 인공지능(AI) 등 IT가 생활에 매우 가까워졌고 다양한 산업에 혁신을 만들며 산업 생태계를 주도하고 있습니다. IT가 함께하는 세상이 찾아온만큼 보안에 대한 인식 역시 높아져야겠습니다.
긴 글 읽어주셔서 감사합니다.
1-1. [NCP] 네이버 클라우드에서의 보안 – Account
안녕하세요. ManVSCloud 김수현입니다.
이전 “[NCP] 네이버 클라우드에서의 보안 – INTRODUCE” 포스팅에 이어 계정 보안을 어떻게 하면 좋을까?에 대한 고찰을 목적으로 작성하게 되었습니다.
1-2. [NCP] 네이버 클라우드에서의 보안 – Account
안녕하세요. ManVSCloud 김수현입니다.
이전 포스팅 “1-1. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT”에 이어 “1-2. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT” 포스팅입니다.
캐싱 데이터가 생성된 Edge로 인해 안전성, 비용, 속도를 보장 받을 수 있으니 Cloudfront는 무조건 사용해야한다?, Cloudfront만 사용하면 무조건 빠르다? 는 정답이 될 수 없습니다.
무조건 사용하지 않습니다. 잘 사용해야합니다. 또한 서비스의 속도는 오직 캐싱만으로 결정되지 않습니다. Rendering, 압축, 개발 소스 등 역시 속도의 원인이 될 수 있으며 최신화를 위해 정적/동적 데이터 구분하여 설정 및 캐싱 예외 처리, TTL 등 고려해야할 사항이 많습니다.
하지만 이 포스팅의 주제는 Cloudfront의 캐시 적중률을 어떻게하면 높일 수 있을까에 대한 주제이므로 캐시 적중률을 높일 수 있는 방법에 대한 내용을 중점으로 다루겠습니다.
How can CloudFront cache hit rate be increased?
CloudFront의 캐시 적중룔, 어떻게하면 높일 수 있을까요?
AWS 가이드에서는 총 7가지가 있다고 합니다.
– CloudFront에서 객체를 캐시하는 기간 지정 – Origin Shield 사용 – 쿼리 문자열 매개 변수를 기반으로 한 캐싱 – 쿠키 값에 따른 캐싱 – 요청 헤더 기반 캐싱 – 압축이 필요하지 않은 경우 Accept-Encoding 헤더 제거 – HTTP를 사용하여 미디어 콘텐츠 제공
7가지 중 3가지 정도만 자세히 알아보도록 하겠습니다. (다소 양이 방대하기때문에 나머지는 최하단 Docs 링크 추가해두었으니 참고 부탁드립니다.)
▶ CloudFront에서 객체를 캐시하는 기간 지정
첫번째 방법으로 CloudFront에서 객체를 캐시하는 기간을 지정해주는 것입니다. Cache-Control max-age의 수치가 길면 길수록 캐시 적중률이 높아집니다. 다만 오리진이 아닌 캐시된 파일을 불러오기에 객체 최신화에 문제가 있습니다. 그렇다면 Cache-Control max-age 수치를 어떻게 주면 좋을까요?
우선 TTL과 Cache-Control에 대해서 알아봅시다.
브라우저 캐시 TTL은 최종 사용자 브라우저가 리소스를 캐시하는 시간입니다. 이 리소스의 경우 TTL이 만료 될 때까지 브라우저 로컬 캐시에서 제공하며 만료 시 브라우저가 재요청을 하게됩니다. 이때 TTL은 해당 컨텐츠가 있는 원본 서버의 Cache-Control을 참고하게 됩니다. 예를들어 원본 서버에서 Cache-Control 설정이 public; max-age=60로 설정되어있을 경우 60초의 시간 동안 브라우저 로컬 캐시에 저장됩니다.
Cache-Control은 응답을 캐시할 수 있는 사용자와 해당 조건 그리고 기간을 제어하는데 즉, 웹 컨텐츠 캐시 정책을 컨트롤 하는 지시문이라 볼 수 있습니다.
Cache-Crontrol에 대한 링크를 추가하였으니 참고하시면 좋을듯합니다.
Cache-Control – HTTP | MDN
Cache-Control 일반 헤더 필드는 요청과 응답 내의 캐싱 메커니즘을 위한 디렉티브를 정하기 위해 사용됩니다. 캐싱 디렉티브는 단방향성이며, 이는 요청 내에 주어진 디렉티브가 응답 내에 주어진 디렉티브와 동일하다는 것을 뜻하지는 않는다는 것을 의미합니다.
Cache-Control 설정은 웹 사이트 성능 최적화에 중요한 역할을 합니다. Cache-Control은 컨텐츠 유형별로 다른 설정을 해준다면 웹 사이트 성능 최적화에 좋은 결과를 기대할 수 있을 것입니다.
컨텐츠 유형은 크게 정적 컨텐츠(Static Contents)와 동적 컨텐츠(Dynamic Contents)로 나뉩니다.
정적 컨텐츠는 css, js, png, jpg, html 파일 등이 대표적이며, 동적 컨텐츠는 업데이트가 잦아 항상 최신화가 필요하거나 요청마다 다른 응답을 주어야하는 리소스들이 되겠습니다.
정적 컨텐츠는 제가 포스팅 시 업로드한 이미지,영상 파일들이나 우리가 흔히 게임을 하기위해 다운로드를 받는 소프트웨어의 경우 TTL이 높아도 상관이 없습니다. 다만 우리가 보는 뉴스 기사들은 TTL이 높을 경우 빠르게 최신 뉴스를 볼 수 없게 될 것입니다. 그러므로 각 컨텐츠 별로 다르게 설정적 컨텐츠는 제가 포스팅 시 업로드한 이미지,영상 파일들이나 우리가 흔히 게임을 하기위해 다운로드를 받는 소프트웨어의 경우 TTL이 높아도 상관이 없습니다.다만 우리가 보는 뉴스 기사들은 TTL이 높을 경우 빠르게 최신 뉴스를 볼 수 없게 될 것입니다. 그러므로 같은 정적 컨텐츠라도 다르게 설정해줄 필요가 있겠습니다.
제 블로그에 올라간 이미지 파일들은 이미지가 변경되어야 할 이유가 크게 없습니다. 이 경우 아래와 같은 예시로 Cache-Control을 사용할 수 있겠습니다. 예시) max-age = 31536000;(브라우저) 또는 s-maxage=86400(프록시와 같은 공유 캐시에만 적용) max-age의 최대치는 31536000 입니다.
날씨와 같이 1분 주기로 최신화를 하고 싶다면 아래와 같이 할 수 있겠습니다. 예시) public; max-age=60 또는 no-cache; max-age=60 등의 방법
동적 컨텐츠는 항상 최신화가 필요할 것입니다. 항상 최신화를 위해 아래 예시의 방법이 있습니다. 예시) no-cache, max-age=0 또는 private, no-store 등의 방법
제 블로그 역시 Cache-Control이 적용되어있습니다.
Apache를 이용하여 Cache-Control 헤더를 사용한다면 .htaccess를 이용하여 아래와 같은 방법을 사용할 수 있습니다.
<filesMatch ".(ico|jpg|jpeg|png|gif)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=86400, public"
</filesMatch>
HTTP Caching | Web Fundamentals | Google Developers
Dave is a Tech Writer
제 블로그의 이미지 파일들은 AWS S3에 있습니다. 그렇다면 이 S3에 있는 이미지 파일들에게 Cache-Control 설정은 해줄 수 없을까요?
가능합니다. 우선 S3의 해당 버킷을 선택한 뒤Cache-Control을 설정할 파일 또는 디렉토리를 선택합니다. 그리고 [작업]-[작업 편집]-[메타데이터 편집]을 선택 클릭하면 메타데이터 편집을 통해 Cache-Control을 수정 및 설정할 수 있습니다.
자 그럼 이제 CloudFront에서 객체를 캐시하는 기간을 설정하는 방법에 대해 알아 보겠습니다.
Cloudfront의 [Behaviors]에서 설정할 수 있습니다.
또한 아래 사진처럼 Create Behavior로 Path Pattern을 나누어 우선 순위를 설정한 뒤 각 경로나 파일마다 다르게 설정할 수도 있습니다.
수정이 필요한 Behavior를 선택 후 [Edit]을 누르면 아래와 같은 창으로 이동합니다. Cache and origin request settings을 선택해줄텐데 직접 수정하려면 아래 [Use legacy cache settings]를 선택해주어야합니다.
[Use a cache policy and origin request policy]를 선택하여 Managed-CachingOptimized를 사용할 경우 관리형 캐시 정책에 대한 아래 Docs를 참고하면 되겠습니다.
Using the managed cache policies – Amazon CloudFront
Use a cache policy that’s managed by Amazon CloudFront instead of creating and managing your own.
legacy cache settings를 선택할 경우 아래 추가로 입력할 수 있는 창이 생깁니다. Object Caching을 Customize로 체크해줄 경우 아래 TTL 값을 원하는 값으로 수정이 가능하게됩니다.
* [참고] Cache Based on Selected Request Header가 요청 헤더 기반 컨텐츠 캐싱을 지정해주는 것이고 Query String Forwarding and Caching은 쿼리 문자열 매개 변수를 기반으로 한 캐싱, Forward Cookies가 쿠키 값에 따른 캐싱에 해당됩니다. 아래에서 Query String Forwarding and Caching에 대해 추가로 다룰 예정입니다.
지금까지 위에서 다룬 TTL 값을 변경하는 방법을 알아보았습니다. 다만 다음과 같은 특이 케이스가 있을 것입니다.
??? : ” 정적 컨텐츠였는데 지금 이미지 하나를 급하게 최신화 해야합니다. 하지만 Cloudfront에 기존 TTL 값이 너무 높게 설정이 되어있습니다. 어떻게 방법이 없을까요? “
있습니다. [Invalidation]을 사용한다면 캐시가 만료되기 전에 파일의 내용을 갱신할 수 있습니다. 이는 캐시 무효화 기능인데 CloudFront Edge 로케이션에 저장된 캐시를 삭제해줍니다.
여기까지 CloudFront에서 객체를 캐시하는 기간을 지정하여 캐시 히트율을 높이는 첫번째 방법에 대해 알아보았습니다.
▶ Origin Shield 사용
두번째 방법으로는 Origin Shield를 사용하는 방법이 있겠습니다. Origin shield는 CloudFront 캐싱 인프라의 추가 계층으로 Origin 앞에 추가적인 캐싱 계층을 제공해줍니다. 모든 캐싱 계층에서 Origin에 대한 모든 요청이 Origin shield를 통과하기에 CloudFront 배포의 캐시 적중률을 개선하는데 큰 도움이됩니다.
또한 Origin의 부하를 최소화하며 가용성을 높여 운영 비용을 줄이는 데에 큰 도움이 됩니다. 캐시에 없는 컨텐츠에 대한 요청은 동일한 객체에 대한 다른 요청과 통합되어 Origin으로 가는 요청이 하나만 발생하게 되는데 이로 인해 동시 요청 수를 줄일 수 있으며 최대 로드, 트래픽 급증 중에 Origin의 가용성을 유지할 수 있고 동적 패키징, 이미지 변환 및 데이터 전송과 같은 비용을 줄일 수 있습니다.
Feb 20, Origin Shield 사용 전 (21일에 적용)Feb 23, Origin Shield 사용 2일 후 (21일에 적용)
(포스팅 당일은 캐싱되지 않은 새로운 컨텐츠가 존재하여 cf-cache-status : MISS가 발생할 수 있습니다.)
제 블로그에 적용 당시 Origin shield입니다. 적용 후 그래프의 캐시 적중률(Hits)이 상승한 것을 볼 수 있습니다.
Origin Shield 설정 – 1Origin Shield 설정 – 2
위와 같은 방법으로 Origin Shield 설정이 가능합니다.
그외에도 Origin Shield는 CloudFront의 리전 엣지 캐시를 활용하며 CloudFront 위치에서 Origin Shield 로 연결할 때 각 요청에 대해 활성 오류 추적을 사용하여 Default Origin Shield 를 사용할 수없는 경우 요청을 보조 Origin Shield 위치로 자동 라우팅하므로 고 가용성까지 갖췄습니다.
▶ 요청 헤더 기반 캐싱
마지막으로 요청 헤더 기반 캐싱에 대해 알아보겠습니다.
위에서 언급했듯 요청 헤더 기반 캐싱은 Behavior을 [Edit] 시Query String Forwarding and Caching를 선택할 수 있습니다.
이는 Query String을 캐시 구분자로 사용할지 물어보는 것입니다.
# None(캐시 향상) : 이를 선택할 경우 모든 쿼리스트링에 대해 캐시합니다. # Forward all, cache based on whitelist : whitelist를 선택하여 값을 입력할 경우 whitelist에 입력된 쿼리스트링에 대해서만 캐시가 되지 않고 나머지는 캐시가 됩니다. # Forward all, cache based on all : all을 선택하게 되면 캐시를 하지 않게됩니다.
None과 all은 캐시 된다/안된다이니 whitelist를 잘 써야봐야겠습니다. 아래 사진으로 예를 들어보겠습니다.
제 블로그는 도메인명 뒤에 ?p가 붙습니다. ex)https://manvscloud.com/?p=612
만약 제가 포스팅되는 글들은 캐시되지 않고 오리진에서 최신화하여 불러왔으면 좋겠다고 했을 때 위와 같이 설정해줄 수 있습니다. whitelist에 p를 넣어주면 https://manvscloud.com/? 뒤에 p의 쿼리스트링에 대해서 캐시하지 않고 항상 최신화하게 됩니다.
그렇다면 이 쿼리스트링을 여러개 사용해야한다면 어떤 방법이 있을까요? 예를 들어 이미지가 요청할 때마다 항상 다른 사이즈로 리사이징되어야 하는 경우입니다.
첫 요청 시 /?w=200&h=150&f=webp&q=90 으로 요청했는데 이후 /?w=100&h=300&f=webp&q=90으로 요청이 올 경우 바로 리사이징 된 이미지를 보여주어야합니다.
위와 같은 방법을 사용할 수 있습니다. 각 w,h,f,q 쿼리스트링에 대한 whitelist를 입력하여 해당 쿼리스트링 요청 시 캐싱되지 않고 오리진에서 불러올 수 있도록하는 것입니다.
이 방법을 사용한다면 원하는 것만 최신화 하고 나머지는 항상 캐싱되니 캐시를 잘 사용한다고 볼 수 있겠습니다.
캐시 적중률이 높다는 것은 hit율만 높고 최신화가 되지 않는 것을 말하는 것이 아닙니다. 최신화 되어야할 부분은 최신화 되면서 캐싱이 되어야 비로소 캐시가 잘 적중했다라고 생각됩니다.
지금까지 캐시 적중률을 높이는 3가지 방법에 대해 자세히 알아보았습니다. 이 외에도 나머지 4가지 방법이 더 있습니다. 제일 하단 링크에 추가된 링크를 통해 나머지 4가지 방법도 찾아보시길 바랍니다.
Opinion
검색 엔진 최적화(SEO)에는 웹 사이트 속도와 상관 관계가 있다고 합니다. 조사에 따르면 웹 페이지가 출력되는데에 4초 이상이 소요될 경우 75%의 사람들은 이미 해당 웹 사이트를 종료한다고 합니다.
캐시 적중률을 높여 웹 페이지의 속도를 빠르게 해보시는 것은 어떠신가요? 많은 분들에게 도움되는 포스팅이 되었길 바랍니다.
(원래 추가로 Cloudfront + Lambda@Edge를 활용한 Image Resizing에 대한 포스팅도 첨부하여 이미지 리사이징을 통해 SEO 최적화하는 방법을 더하려 했으나… 왜 안되는지 잘 모르겠습니다?… )
CloudFront의 캐시 적중률을 높여보자는 게 그만 내용이 꽤 길어졌습니다. 처음에 작성하려 했던 양보다 훨씬 많아졌네요… 7가지 중에 3가지만 했는데도 이 정도 양이니… 나머지 4개는 제가 여러분들에게 드리는 숙제인걸로…! 찾아보면서 공부하는 재미가 있더라구요? 홧팅!!
다음 AWS 공부는 Elasticache나 Elastic Beanstalk을 생각하고 있지만 곧 NCP 시험과 Kubernetes 일정으로 인해 다음 AWS 포스팅까지는 다소 시간이 걸릴듯합니다.
긴 글 읽어주셔서 감사합니다.
References
Increasing the proportion of requests that are served directly from the CloudFront caches (cache hit ratio) – Amazon CloudFront
Describes how to improve performance by increasing the proportion of your viewer requests that are served directly from the CloudFront cache instead of going to your origin servers for content.
