Browsing Tag

네이버

NCP

2-2. [NCP] 네이버 클라우드에서의 보안 – Server (내부 방화벽을 이용한 GEOIP)

안녕하세요. ManVSCloud 김수현입니다.

오늘 포스팅은 이전 포스팅 주제였던 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를 사용할 것입니다.

[Environment]
Naver Cloud Platform : centos-7.8-64

※ 기본 설정 및 설치 😎

[root@manvscloud-dev-pub-kr1 ~]# sestatus 
SELinux status:                 disabled

[root@manvscloud-dev-pub-kr1 ~]# yum install -y iptables*
yum install lrzsz libtool wget patch pcre-devel lua-devel libxml2-devel ncurses-devel zlib zlib-devel libtermcap-devel libc-client-devel bison gcc g++ cpp gcc-c++ curl curl-devel make automake unzip zip xz -y

[root@manvscloud-dev-pub-kr1 ~]# yum install -y "kernel-devel-uname-r == $(uname -r)"

[root@manvscloud-dev-pub-kr1 ~]# yum install -y yum install perl-Text-CSV_XS perl-NetAddr-IP perl-CPAN.noarch

※ 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 수정하여 룰셋 적용해서 사용하시면 됩니다.


TIP & Personal Comments and Wrap-up

windows firewall

Windows에서 역시 국가 기반 차단이 가능합니다.

Powershell을 이용한 방화벽 컨트롤 및 IPSec 설정의 방법이 존재하는데 이번 편에서는 따로 다루지 않고 IPsec 편에서 추가적으로 설명하도록 하겠습니다.

또한 Apache와 Nginx 등 소프트웨어단에서 국가 기반 차단을 할 수도 있습니다.
이후 이러한 소프트웨어단에서 국가 기반 차단을 하는 방법도 포스팅할 것입니다.

위 링크는 WHOIS입니다.
서버내에서 공격성 접근 확인 시 해당 IP를 위 사이트에서 검색할 경우 어느 나라의 IP인지 확인이 가능합니다.

국가 기반 차단 시 필요한 국가 코드 및 WHOIS 조회 시 국가코드가 어느 나라인지 확인할 수 있는 국가 코드 조회 사이트도 참고하시면 좋을듯합니다.

긴 글 읽어주셔서 감사합니다.


NCP

2-1. [NCP] 네이버 클라우드에서의 보안 – Server (ACG)

안녕하세요. ManVSCloud 김수현입니다.

“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 – ACG
VPC – ACG

ACG에서는 TCP, UDP, ICMP 프로토콜에 대해 규칙 설정이 가능하며 192.168.0.1(단일), 10.0.1.0/24(대역), 0.0.0.0/0(전체), manvscloud-acg(ACG 이름) 으로 접근소스 지정이 가능합니다. (manvscloud.com과 같이 도메인은 불가능)

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를 관리하는 방식은 아래와 같습니다.

  1. admin-acg (프로젝트 공통 관리자 관리 정책 ACG)
  2. web-acg, mysql-acg, was-acg 등 (공통 서비스 관리 정책 ACG)
  3. *-acg (특정 서버에만 적용되어야하는 정책 ACG)

더 좋은 ACG 사용 방법이 있다면 댓글로 의견 부탁드립니다.

위 정책은 웹 서버에 대한 web-acg 입니다.
제가 80포트를 0.0.0.0/0이 아니라 왜 10.0.13.0/24와 10.0.33.0/24 으로 열어두었을까요?

이유는 바로 제가 LB와 연결을 해놓았기때문입니다.
많은 고객분들이 웹 서버와 LB를 함께 사용하십니다.

[root@manvscloud-web-pub-kr2 ~]# tail -f /var/log/httpd/access_log 
10.0.13.11 - - [25/May/2021:07:15:15 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.11 - - [25/May/2021:07:15:15 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
Load Balancer

만약 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에 대한 내용에 이어 서버 내부 방화벽 활용 방법을 먼저 포스팅하려고 합니다.

긴 글 읽어주셔서 감사합니다.


NCP

0. [NCP] 네이버 클라우드에서의 보안 – Introduce

안녕하세요. ManVSCloud 김수현입니다.

오늘은 국내 클라우드 Naver Cloud Platform에서의 보안을 간단히 소개해보는 포스팅을 작성해보려합니다.

포스트 코로나 시대, 즉 접촉없이 연결되는 언택트 시대가 Covid-19의 영향으로 예상보다 빠르게 일상생활의 트렌드를 바꾸어가고 있습니다.
온라인 교육, 화상 면접, 배달 서비스 등 시대에 맞게 비대면 서비스가 증가했으며
IT 분야 역시 이러한 변화로 인해 클라우드 서비스가 많이 사용되고 있습니다.

https://www.parkmycloud.com/blog/aws-vs-azure-vs-google-cloud-market-share/

전통적인 온프레미스 환경에서 클라우드로 변화하거나 온프레미스와 퍼블릭 클라우드를 함께 하이브리드 클라우드로 운영하시는 사용자들이 상당히 많아졌고 공공기관이나 금융기관 역시 이러한 클라우드 서비스에 대해 고려해보게 됩니다.

(네이버 클라우드 플랫폼 – 공공기관용)

(네이버 클라우드 플랫폼 – 금융기관용)

또한 국내 데이터가 해외 클라우드 서버에 저장되는 것부터 그런 데이터들이 보안 문제로 인해 유출되는 부분들까지 많은 고민이 될 것입니다.
네이버 클라우드에서는 국내 공공기관용으로 보안수준을 강화한 클라우드 서비스를 제공하고 금융기관과 핀테크 기업의 조건에 맞는 맞춤형 서비스를 제공하여 데이터를 국내에 저장하며 맞춤형 클라우드 서비스를 사용할 수 있어 더욱 신뢰성과 안정성이 있습니다.

CSA(Cloud Security Alliance) 자료에 따르면 클라우드 환경에서의 11가지 두드러진 위협/위험 및 취약점이 아래와 같이 존재한다고 말합니다.

  1. Data Breaches (데이터 침해)
  2. Misconfiguration and Inadequate Change Control (잘못된 구성 및 부적절한 변경 제어)
  3. Lack of Cloud Security Architecture and Strategy (클라우드 보안 아키텍처 및 전략 부족)
  4. Insufficient Identity, Credential, Access and Key Management (불충분한 ID, 자격증명, 액세스 및 키 관리)
  5. Account Hijacking (계정 하이젝킹)
  6. Insider Threat (내부자 위협)
  7. Insecure Interfaces and APIs (안전하지 않은 인터페이스 및 API)
  8. Weak Control Plane (약한 컨트롤 플레인)
  9. Metastructure and Applistructure Failures (메타 구조 및 애플리케이션 구조 오류)
  10. Limited Cloud Usage Visibility (제한된 클라우드 사용 가시성)
  11. Abuse and Nefarious Use of Cloud Services (클라우드 서비스의 남용 및 악의적인 사용)

위 보안 위협에 대한 자세한 내용은 아래 사이트에서 다운로드 받을 수 있으니
취약점에 대한 자세한 내용을 알고싶으신 경우 자료 참고하시면 좋을듯 합니다.

이런 보안 위협에 대한 대비는 앞으로 더욱 중요한 사항이 될 것으로 보입니다.


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 상품은 이 부분을 지원하는구나 또는 어떤 통제 규격을 적용해야하구나를 자세히 알려줍니다.

또한 “정보시스템 관련 자산(하드웨어, 운영체제, 상용 소프트웨어, 패키지 등) 변경에 대한 절차를 수립·이행 하고 있는가?”라는 내용에 마우스 커서를 올리면 해당 내용에 대한 통제를 구현하는데 이용되는 상품, 통제를 적용해야 하는 상품, 통제를 구현하는데 이용되는 상품을 알 수 있습니다.


마무리

6월 18일에 “[6월 Intermediate] 네이버클라우드플랫폼 보안 강화 교육” 이라는 주제로
네이버 클라우드 플랫폼에서 교육이 진행됩니다.

현재 아쉽게도 모집은 마감된 상태라 추가적인 신청이 불가능한 상태이므로
제가 해당 교육을 듣고난 후 추가적인 후기 포스팅을 남기고 제가 포스팅하고 있는 “네이버 클라우드에서의 보안” 주제에 빠진 부분을 추가 포스팅으로 채워볼 예정입니다.

다가오는 보안 교육 전에 먼저 “[NCP] 네이버 클라우드에서의 보안”이라는 주제로 포스팅을 진행하게 될 것이며 다음 포스팅은 앞서 간단히 소개된 계정, 네트워크, 서버, 데이터베이스, 스토리지, 감사, 이중화, 백업 등에서의 보안을 하나씩 자세히 다루어보는 내용으로 나누어 포스팅 됩니다.

이제는 클라우드, 인공지능(AI) 등 IT가 생활에 매우 가까워졌고 다양한 산업에 혁신을 만들며 산업 생태계를 주도하고 있습니다.
IT가 함께하는 세상이 찾아온만큼 보안에 대한 인식 역시 높아져야겠습니다.

긴 글 읽어주셔서 감사합니다.


Certificate

NAVER Cloud Platform Certified Professional (NCP) 합격과 시험 후기

안녕하세요. ManVSCloud 김수현입니다.

드디어 Naver Cloud Platform Professional 시험에 합격하였습니다.
2020.06.30 NAVER Cloud Platform Certified Associate 응시 이후
Professional 은 약 10개월만에 시험을 보게되었습니다.

Naver Cloud Professional 시험은 총 3번의 시험을 합격해야 Professional 자격을 얻게됩니다.

200 – NCP(Overview, Compute/Storage) – 2021.05.11 (화)
207 – NCP(Troubleshooting) – 2021.04.15 (목)
202 – NCP(Network/Media, Database/Management/Analytics) – 2021.04.13 (화)

위 3개의 시험을 나누어 보게되었고 아래 자격증을 얻게되었습니다.

◈ NAVER Cloud Platform Certified Professional (NCP)
Issue Date : 2021-05-12


시험 TIP

간단하게 Naver Cloud Platform Professional 시험의 Tip을 적어볼까합니다.

우선 Professional 시험부터는 필기 시험뿐만이 아니라 실기 시험도 존재합니다.
어느정도 사용 경험이 있지 않으면 합격할 수 없으니 실습도 병행하여 준비하셔야겠습니다.
(각 시험별 필기 문제는 약 40문제이며, 실기 문제는 3문제입니다.)

우선 공통적으로 아래 두 사이트를 참고하실 필요가 있는데 설명서의 경우
Overview, Compute/Storage(200)와 Network/Media, Database/Management/Analytics(202) 시험에 필수적으로 과목별 내용을 정독 후 시험 보시는 것을 권장드립니다.

아래 edwith 사이트에서 “Authorized Course – Professional level” 영상 강의를 참고하실 수도 있는데 Troubleshooting(207) 과정을 준비하실 때에 필수적으로 봐주시면 좋을듯합니다.

물론 기존에 현장에서 엔지니어로 일하고 계실 경우Troubleshooting 과목이 가장 쉬운 난이도로 느껴지실 수 있을 것입니다.

개인적으로 느낀 시험 난이도는 아래와 같습니다.

필기 : 200 > 202 > 207
실기 : 200 = 207 > 202

전반적으로 실기 시험의 난이도는 높지 않습니다.
다만 202 시험은 당황하면 자칫 한 문제를 놓칠 수도 있겠구나 싶었습니다.
그리고 200 시험의 경우 서버 생성이 필요하여 서버 생성 시간이 약 20분 정도 소요되는데 여기서부터 이슈가 생깁니다. 나머지 두 문제는 첫번째 문제를 해결해야 풀 수 있으므로 첫 번째에서 막히면 사실상 탈락이라 보아도 될 것같습니다. 필기+실기의 총 시간이 1시간인데 필기에서 많은 시간을 소요하여 실기를 못보는 경우가 생기지 않도록 필기를 잘 준비해야 할 것입니다.

또한 필기를 적절히 풀었는데 서버 생성 시간이 다소 오래 걸려 이에 대해 시험관에게 말할 경우 추가적인 시간을 준다고도 하니 참고하여 당황하지 않길 바랍니다.

실습의 경우 비용이 부담되신다면 위 네이버 클라우드에서 진행하는 교육에 참가해보시기 바랍니다.

네이버 클라우드에서 진행하는 교육을 참가하실 경우 교육 당일부터 그 주의 일요일까지 실습 계정을 사용할 수 있어 교육 후에도 시험을 대비한 실습 테스트가 충분히 가능합니다.

또한 기본적인 실습 감각을 익히기 위해서 “NAVER CLOUD PLATFORM Hands-on Lab” 교육을 신청하시는 것을 추천드립니다. 실습에 대한 경험이 없는 분들이 시작하기 좋은 교육이며 Hands-on Lab의 경우 매달 1,2차로 나누어 자주 하는 교육인만큼 접근성에 있어 상당히 좋은 교육이라 생각됩니다.

실기 준비는 Compute/Storage/Database/Networking/Media/Analytics 카테고리에 있는 제품들을 위주로 실습해보시기 바라며 핵심적인 팁으로는 시험 시간이 필기+실기 합쳐서 1시간으로 정해져있어 한 문제당 시간 소요가 상당히 소모되는 제품은 나오지 않는 것같습니다?
(실습은 VPC 환경에 익숙해지도록 해보시면 좋을듯합니다.)

후기

목표했던 Naver Cloud Platform Professional 자격증을 드디어 얻게되었습니다.
Naver Cloud 시험의 경우 올해 후반기에 출시 예정인 Expert 시험까지 생각중에 있습니다.

코로나로 어디 나가지도 못하고 제한되다보니 가끔 공부에 대한 의지가 꺽일 때가 많습니다.
“나는 원래 카공족이고 집에서는 원래 공부가 안되는데…”라고 하면서.

하지만 한창 공부와 거리가 먼 때에는 코로나가 아니었음에도 불구하고 그럴싸한 이유를 만들어서 하지 않았던 걸로 기억합니다.
만약 지금도 하지 않는다면 앞으로도 어떻게든 이유를 만들어서 안하겠구나.. 생각했습니다. 또, 그런 핑계를 만들어서 하지 않을 사람도 있겠다라는 생각도 듭니다.
이런 때에 열심히 한다면 그것 또한 기회라고 생각합니다.
현재 자신이 처한 상황을 핑계로 아무것도 하지 않는 것보다 기회로 생각하고 나아간다면 이 상황이 끝났을 때 보다 나은 자리에 있으리라 믿습니다.

올해 목표해둔 자격증까지 총 4가지 정도가 남은듯합니다.
남은 자격증도 열심히 준비해서 합격 후 후기로 포스팅해보겠습니다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] Load Balancer 사용 시 웹서버 로그에서 Client IP를 볼 수 있을까?

안녕하세요. ManVSCloud 김수현입니다.

오늘은 Naver Cloud Platform에서 LOAD BALANCER 사용 시에 웹서버 내 로그에 찍히는 IP가 Client IP가 찍히도록 설정하는 방법에 대해 포스팅 하겠습니다.

HTTP 헤더 중 하나인 X-Forwarded-For를 이용하는 방법과 각 소프트웨어의 모듈을 이용하여 Client IP를 식별하는 방법 두 가지에 대해서 알아보겠습니다.


테스트 기본 세팅

해당 이미지를 더블 클릭하시면 큰 화면으로 이미지를 자세히 볼 수 있습니다.

저는 VPC 환경에서 테스트를 진행하였습니다.
(Classic도 동일한 방법으로 가능합니다.)

centos-7.8-64로 생성해주었습니다.
서버 생성 후 Apache를 설치합니다.

[root@manvscloud-web-pub-kr2 ~]# yum install httpd httpd-devel -y
[root@manvscloud-web-pub-kr2 ~]# systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@manvscloud-web-pub-kr2 ~]# systemctl start httpd

테스트 준비는 끝났습니다.
이제 LB가 없을 때, X-Forwarded-For를 사용할 때, 각 소프트웨어의 모듈을 사용할 때에 대해서 살펴보겠습니다.


Load Balancer가 없을 때

우선 Load Balancer가 없을 때 해당 서버로 접근 할 경우 정상적으로 Client IP가 찍힙니다.
(Client – Server)


Load Balancer를 추가했을 때

Application Load Balancer로 생성하였습니다.
index.jsp → index.html
tail -f /var/log/httpd/access_log

Load Balancer를 추가하게되면 위와 같이 Client IP가 아닌 LB의 사설 IP가 찍히게 됩니다.
(Client – LB – Server)

이제 LB가 있는 상태에서 Client IP를 볼 수 있도록 설정해보겠습니다.


X-Forwarded-For

[root@manvscloud-web-pub-kr2 html]# grep -n LogFormat /etc/httpd/conf/httpd.conf 
196:    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
197:    LogFormat "%h %l %u %t \"%r\" %>s %b" common
201:      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio

Apache의 LogFormat을 보면 현재 위와 같이 되어있습니다.
이 LogFormat을 조금 변경해줄 것입니다.

vi /etc/httpd/conf/httpd.conf 를 이용하여 196 라인에 LogFormat을 아래와 같이 변경 해주겠습니다.

    196     LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

기존 LogFormat 가장 앞부분에 %{X-Forwarded-For}i 을 추가해준 것입니다.
이를 추가해준 뒤에 Apache 재시작 1회 진행 후 다시 한 번 로그를 확인해보면 Client IP가 찍히게 됩니다.

웹 접속 시 Client IP가 추가된다.

이 설정은 Apache 뿐만 아니라 Nginx, Tomcat에서도 당연히 설정이 가능합니다.
아래 링크를 참고하면 좋을듯합니다.


Network Proxy Load Balancer

이제 Apache와 Nginx에 모듈을 추가하여 Client IP 식별하는 방법에 대해 알아볼 것입니다.

모듈을 설명하기 앞서 기존에 사용하던 ‘애플리케이션 로드밸런서’에서
‘네트워크 프록시 로드밸런서’로 변경해줄 것입니다.

LB 생성은 크게 다를 것이 없습니다.
다만 Target Group에서 조금 다르게 설정을 해줄 것입니다.

프로토콜은 PROXY_TCP로 해줍니다!
그리고 TargetGroup 설정에서 ProxyProtocol을 클릭해줍니다.

콘솔에서 해줄 작업은 이걸로 끝입니다. 이제 모듈을 추가하러 갑시다!


Apache Module

[root@manvscloud-web-pub-kr2 src]# apachectl -M | grep myfixip

Apache에서는 myfixip 모듈을 이용할 것입니다.
해당 모듈의 경우 기본 내장 모듈이 아니라 아래와 같이 추가해주어야합니다.

[root@manvscloud-web-pub-kr2 html]# cd /usr/local/src
[root@manvscloud-web-pub-kr2 src]# wget --no-check-certificate https://raw.githubusercontent.com/ggrandes/apache24-modules/master/mod_myfixip.c
[root@manvscloud-web-pub-kr2 src]# apxs -aic mod_myfixip.c 
[root@manvscloud-web-pub-kr2 src]# apachectl -M | grep myfixip
 myfixip_module (shared)

myfixip_module이 추가된 것을 확인할 수 있습니다.
이제 httpd.conf에 해당 모듈을 추가해주고 사용할 것입니다.

[root@manvscloud-web-pub-kr2 ~]# cat << EOF >> /etc/httpd/conf/httpd.conf
> LoadModule myfixip_module modules/mod_myfixip.so
> <IfModule mod_myfixip.c>
> RewriteIPResetHeader off
> RewriteIPAllow 10.0.0.0/16  
> </IfModule>
> EOF
[root@manvscloud-web-pub-kr2 ~]# systemctl restart httpd

RewriteIPAllow은 Load Balancer가 있는 대역을 추가해주면 됩니다.
위에서 추가한 Proxy LB로 접속하게 되면 이제 아래와 같이 Log가 남습니다.

Apache myfixip

정말 깔끔하게 Client IP가 보이고 있습니다.
이제 Apache와 함께 많이 사용되고 있는 Nginx에서 설정을 해보겠습니다.


Nginx Module

우선 Nginx는 아래 내용을 참고하면 간단하게 설치가 가능합니다.

[root@manvscloud-web-pub-kr2 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
[root@manvscloud-web-pub-kr2 ~]# yum install nginx
[root@manvscloud-web-pub-kr2 ~]# systemctl start nginx

Nginx에서의 설정도 어렵지 않습니다.
Nginx에서는 realip module이 있는지 확인해주어야합니다.

nginx -V 2>&1 | grep 'http_realip_module'
해당 이미지와 같이 모듈이 존재한다면 준비는 완료되었습니다.

vi /etc/nginx/nginx.conf 로 nginx의 config파일을 아래와 같이 변경해줄 것입니다.

#    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
#                      '$status $body_bytes_sent "$http_referer" '
#                      '"$http_user_agent" "$http_x_forwarded_for"';

    log_format  main  '$proxy_protocol_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';


        proxy_set_header X-Real-IP         $proxy_protocol_addr;
        proxy_set_header X-Forwarded-For   $proxy_protocol_addr;

        server
        { 
                root    /usr/share/nginx/html;
                listen 80  proxy_protocol;
                set_real_ip_from 10.0.2.0/24;
                real_ip_header proxy_protocol;     
        }

기존 log_format은 주석처리하고 그 아래에 전부 새로 추가한 내용들입니다.

  1. $remote_addr$proxy_protocol_addr로 변경해줍니다.
  2. proxy_set_header을 추가해줍니다.
  3. proxy protocol과 real_ip 설정도 해줍니다.

설정이 끝난 뒤 nginx를 1회 재시작하고 로그를 확인해봅니다.

Apache와 동일하게 Nginx도 Proxy LB로 접속하면 Client IP가 그대로 남는 것을 확인할 수 있었습니다.

이로써 LOAD BALANCER 사용 시에도 웹서버 로그에서 CLIENT IP를 볼 수 있다는 것을 알 수 있습니다.
이 글을 읽으시는 분들께서도 해당 포스팅을 참고하여 서버에서 Client IP가 보이도록 설정해보시는 건 어떠신가요?

웹 로그에서 Client IP를 확인하는 일은 꽤 많은 것같습니다.
가끔 MaxClients 설정이 낮지않은데 MaxClients 수치보다 많은 프로세스로 인해 확인을 해보면 특정 IP가 ESTABLISHED와 CLOSE_WAIT 을 반복하여 대량의 CLOSE_WAIT를 남겨 MaxClients가 순식간에 늘어나는 것을 많이 보았습니다.

그 특정 IP를 log파일에서 여러 명령어와 조합하여 wc -l 로 뽑아내면 공격성 및 이상 접근으로 의심되는 접근을 빠르게 판단하고 차단 / 조치 할 수 있게되는 것 같습니다.

해당 포스팅은 여기서 마무리해보려 합니다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] Kubernetes Service를 활용한 컨테이너 관리 후기

안녕하세요. ManVSCloud 김수현입니다.

오늘은 2월 19일 Naver Cloud Platform에서 진행한
“KUBERNETES SERVICE를 활용한 컨테이너 관리” 교육 후기에 대해 써볼까합니다.

우선 이번 교육의 경우 Intermediate 교육인데 Intermediate 교육은
[Big Data], [Kubenetes], [DevOps], [Media], [A.I], [Security] 과정이 있으며
현재 Naver Cloud Platform에서 알려진 전반기 교육 일정은 아래와 같으므로 참고하시면 좋을듯합니다.

1월 – Big Data
2월 – Kubenetes
3월 – DevOps
4월 – Media
5월 – A.I
6월 – Security


Theory

오전엔 Kubernetes이 대한 이해를 도울 수 있을만한 이론을 중심으로 강의가 시작되었습니다.

Naver Cloud Platform에서의 Kubernetes Service인 NKS에 대한 강의만 하는 것이 아니라
Kubernetes가 무엇인지, 왜 사용해야하는지, 어떻게 사용되고 있는지도 배울 수 있었습니다.

Docker에 대한 내용도 많이 언급되었는데 Docker는 저도 가끔 가벼운 테스트를 할 때 따로 도커를 이용하여 테스트를 할 때가 많습니다.
최근에 포스팅했던 도커로 설치한 jupyter notebook도 nginx proxy를 추가하여 잘 사용하고 있습니다.

Docker를 사용해보지 않으셨다면 Kubernetes를 사용하기 전에 Docker를 먼저 경험해보는 것을 권장합니다.


LABS

오후 시간부터는 실습이 이루어졌습니다.
[클러스터 생성], [Container Registry를 이용한 IMAGE 관리], [POD 운영/관리] 등 다양한 실습이 진행되었으며 실습 교재도 배포되어 혼자 실습을 해도 따라할 수 있을 만큼 잘 만들어져있었습니다.

물론 교재 배포 시 word파일에서 pdf파일로 변경되며 생각과는 다른 부분이 생겨 실습 중 어려움을 겪는 분들도 있었습니다.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

배포된 교재에 위와 같은 부분이 있는데 그대로 복사하여 붙여넣게 되면 정상적인 yum 설치가 되지않습니다. gpgkey 부분이 pdf파일로 바뀌며 나뉘어 진듯 합니다.

pdf를 그대로 복사해버리면 빨간색 체크박스처럼 되었기에 yum 설치가 되지않습니다.
아래 파란 체크박스처럼 되어야하는 것입니다.
이 부분을 해결하며 문득 리눅서님이 말씀해주신 것들이 떠올라 링크 남겨봅니다.

실습 진행 중 쿠버네티스 설치와 웹 서비스 테스트 경험이 있었기에 큰 어려움은 없었습니다.

NKS에서는 VPC 기준 kubernetes 1.16.14 버전과 1.17.11 버전을 지원했습니다.
NKS를 사용한다면 NCP 기존 서비스(대표적으로 모니터링)와 연계하여 사용할 수 있고 조금 더 간편한 느낌이 있습니다.

대부분의 실습을 다 끝마쳤고 실습했던 부분은 나눠서 추가 포스팅을 해볼 생각입니다.
따로 교재가 없어도 NCP에서 제공하고 있는 설명서와 API 참조서가 있어 도움이 됐습니다.

배포된 교재에서 부족한 부분은 아래 링크를 참고했습니다.

실습 중 조금 당황한 부분이 있었는데 nks-metrics-exporter 생성 중에 nrn 값을 잘못넣어
pod가 정상적으로 올라오지 않고 CrashLoopBackOff 가 발생한 부분이 있었습니다.

[root@manvscloud-k8s-pub-kr2 lab5]# kubectl get pods
NAME                                   READY   STATUS             RESTARTS   AGE
apache-deployment-6f4bdc4b79-8z6vw     1/1     Running            0          33m
apache-deployment-6f4bdc4b79-hrr79     1/1     Running            0          33m
apache-deployment-6f4bdc4b79-nnv79     1/1     Running            0          33m
apache-pod                             1/1     Running            0          37m
nks-metrics-exporter-df9c85df4-jrbs6   0/1     CrashLoopBackOff   6          8m56s

문제는 정상적인 nrn값을 다시 넣고도 Running 상태로 돌아오지 않아 기존 pod를 삭제하고 재생성 했습니다. 혹시 저와 같은 케이스가 생긴 분이 있으실까봐 이 방법을 남깁니다.
kubectl get pod [pod이름] -o yaml | kubectl replace –force -f-

[root@manvscloud-k8s-pub-kr2 lab5]# kubectl get pod nks-metrics-exporter-df9c85df4-jrbs6 -o yaml | kubectl replace --force -f-
pod "nks-metrics-exporter-df9c85df4-jrbs6" deleted
pod/nks-metrics-exporter-df9c85df4-jrbs6 replaced

다시 kubectl get pods를 해보면 기존 CrashLoopBackOff 이던 pod는 Terminating 되고 새 pod가 정상적으로 Running되는 것을 알 수 있습니다.

[root@manvscloud-k8s-pub-kr2 lab5]# kubectl get pods
NAME                                   READY   STATUS        RESTARTS   AGE
apache-deployment-6f4bdc4b79-8z6vw     1/1     Running       0          34m
apache-deployment-6f4bdc4b79-hrr79     1/1     Running       0          34m
apache-deployment-6f4bdc4b79-nnv79     1/1     Running       0          34m
apache-pod                             1/1     Running       0          38m
nks-metrics-exporter-df9c85df4-jrbs6   0/1     Terminating   0          8s
nks-metrics-exporter-df9c85df4-zb2qd   1/1     Running       0          17s

이후 메트릭 생성이 잘 되어 Cloud Insight로 Monitoring 되는 것까지 확인할 수 있었습니다.


The End

Kubernetes를 테스트 하기위해 클라우드 또는 서버로 비용이 내는 것이 부담스러울 수 있기에 Kubernetes를 도입하기 전에 VMware나 VirtualMachine으로 테스트를 해볼 수도 있습니다.

이전에 제가 포스팅했던 글인데 참고하면 좋을듯합니다.
이전 블로그에서는 소스코드가 지원이 되지않아 yaml 파일이 띄워쓰기 없이 다 붙어있는데
이 부분은 빠른 시일내에 수정할 예정입니다.
yaml 파일 띄워쓰기 전부 수정 해두었습니다.
(yaml파일은 문법상 띄워쓰기와 빈 칸을 잘 사용해줘야합니다.)

3월은 DevOps 교육이 계획되어 있습니다. DevOps 교육도 참가할 예정입니다.
그리고 현재 NCP 교육 및 행사 일정에 “[3월] NAVER CLOUD PLATFORM Hands-on Lab”도 모집중이니 관심있으시면 신청해보시기 바랍니다.

KUBERNETES SERVICE를 활용한 컨테이너 관리 강의 해주신 NCP 강사분께 감사의 인사 올리며 포스팅을 마무리 하겠습니다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] Hands-on Lab 후기

안녕하세요. ManVSCloud 김수현입니다.

오늘은 2월 5일에 신청하여 들었던 Naver Cloud Platform HANDS-ON LAB 후기를 써볼까합니다.

이번 Hands-on Lab은 전체적인 서비스 구성을 소개하고 실습하는 과정으로 처음 네이버 클라우드를 접하는 분들에게 많은 도움이 되었을 것이라 생각됩니다.

저같은 경우 네이버 클라우드 플랫폼의 Associate 기술 자격증을 공부하며 익힌 내용이 있었지만 클래식 환경에서의 이론/실습만 해보았기에 2020. 09. 17 에 출시된 VPC, 즉 Virtual Private Cloud에 대한 이론/실습의 경험이 없어 이번 기회에 참가하여 공부하였습니다.

교육 시간은 10:00~16:00이었으며 상당히 알차게 구성되어있었습니다.
중간에 쉬는 시간과 점심 시간이 있었지만 긴 시간동안 쉬지않고 교육해주신 네이버 클라우드 강사분에게 감사의 인사를 올립니다.

교육은 클라우드 컴퓨팅은 무엇인가?, 네이버 클라우드 플랫폼 제품 소개 등으로 시작하여 실습 및 질문/답변으로 마무리되었습니다.
플랫폼을 쉽고 편하고 비용효율적으로 구성, 활용하려면 해당 플랫폼 제품의 종류와 기능을 아는 것은 많은 도움이 됩니다. 다양한 상품군을 하나씩 상당히 잘 설명해주셨습니다.


네이버 클라우드 플랫폼은 Classic과 VPC 환경으로 나누어져있으며,
실습은 VPC 환경에서 이루어졌습니다.
(VPC는 논리적으로 격리하여 가상 네트워크를 제공한 공간이라고 볼 수 있습니다.)

개인 계정으로 실습할 경우 비용이 발생하므로 해당 교육 참가 시 실습 계정이 주어집니다.

간단하게 VPC 환경에서는 어떻게 다를까 이런저런 실습을 해보았습니다.

VPC 환경에서 실습해보며 Classic과의 차이를 알아보았고,
해보는 김에 NCP에서 아직 제가 사용해보지않은 이미지 리사이징 변환/전송 기능이 있는 Image Optimizer도 써보게 되었습니다.

이미지 리사이징 기능은 AWS에서 이미지 리사이징 했던 것보다 훨씬 간편하게 할 수 있도록 되어있어 너무 편했습니다.

또한 이번 HANDS-ON LAB을 통해 모바일에서도 콘솔을 볼 수있는 앱이 있다는 것을 알게 되었습니다… 나온지 꽤 오래된 거같은데 이제 알았어요…

스토어에서 네이버 클라우드 콘솔, naver cloud console 등을 검색하여 다운로드 받을 수 있으며 해당 앱을 이용해서 간단한 서버 정지/시작 등과 같은 다양한 서비스를 사용할 수 있었습니다.

이제 제 모바일 앱에 클라우드 콘솔 앱이 3개가 생겼네요

마지막으로 HANDS-ON LAB과 같은 교육 및 행사 신청하는 방법을 추가로 적어두었습니다.
많은 분들이 네이버 클라우드에서 주최하는 교육/행사를 통해 배움이 있기를 바랍니다.

  1. https://www.ncloud.com/ 에 접속합니다.
  2. [고객지원·FAQ] [교육 및 행사 신청하기]를 눌러줍니다.
  3. 아래 그림과 같은 페이지가 나옵니다. 모집중인 교육/행사를 신청하여 참가합니다.

마지막으로 제가 시스템 엔지니어로써 올바른 길을 갈 수 있도록 도와주신 리눅서님이
저의 상사 동료에서 이제는 Naver Cloud Platform과 함께 하게된 것을 축하드리며 새로운 시작을 항상 응원합니다.

긴 글 읽어주셔서 감사합니다.