금요일, 18 8월 2017 / Published in 클라우드 활용팁

최근 들어 구글, 모질라 등 많은 인터넷 관련 기업들이 로그인 기능을 갖춘 홈페이지는 반드시 HTTPS를 적용할 것을 권고하고 있다. 심지어 구글의 경우 홈페이지에 로그인 기능이 있음에도 HTTPS를 적용하지 않을 경우 검색 결과에서 하단으로 내리는 등의 패널티를 주고 있습니다.

HTTPS란 데이터를 주고받는 신호를 암호화하지 않는 http(일반 페이지)와 달리 인터넷 보안 표준인 TLS(Transport Layer Security) 통신 기술을 활용해 AES 128 또는 256 비트 수준으로 암호화된 HTTP를 의미한다. 홈페이지에 HTTPS를 적용하면 ’악의를 가진 제 3자(=해커)가 서버(홈페이지)와 클라이언트(사용자) 간의 통신을 중간에서 훔쳐보는 것(패킷 스니핑)’을 매우 어렵게 만들어줍니다.

오늘 필자는 Azure PaaS상의 웹 앱에 SSL 인증서를 등록하여 HTTPS 서비스를 하는 방법에 대해 소개하려고 합니다.

 

앱 서비스 SSL 인증서 생성 및 구성

Microsoft Azure Cloud에서는 GoDaddy와 파트너쉽을 맺고 앱 서비스 인증서(ASC, App Service Certificate)를 생성, 관리 및 서비스 기능을 제공하고 있습니다.

 

1단계 – Azure 포털에 로그인

우선, ASC를 생성하기 위해 Azure Portal에 접속합니다.

App Service Certificate 검색

 

2단계 – SSL 인증서 주문하기

Azure Portal의 상단 검색어 입력란에 ‘App Service Certificate’를 입력하고 검색합니다.
아래와 같은 결과 페이지에서 ‘App Service Certificate 만들기’ 버튼을 클릭합니다.

App Service Certificate 만들기

아래의 화면과 같은 첫 번째 생성단계에서는 적절한 인증서 이름과 도메인 호스트 이름을 입력하고 인증서 SKU를 선택합니다.

App Service Certificate 기본 정보 입력

S1 표준(Standard)
SSL 인증서를 root 도메인과 www 서브도메인에 대해서만 바인딩하려면 이 옵션을 선택합니다. 예를 들어 위 화면의 예에서는 devmaru.xyz와 www.devmaru.xyz가 SSL 바인딩이 가능합니다.

W1 와일드카드(Wildcard)
SSL 인증서를 root 도메인과 모든 1차 서브도메인과 바인딩하려면 이 옵션을 선택합니다.

주의 1)
ASC는 오직 1차 서브도메인에 대해서만 SSL 인증서를 지원하고 있다는 점입니다. 즉, demo.devmaru.xyz와 같은 서브도메인에 대해서는 이 옵션을 선택하면 바인딩이 가능하지만 groupware.demo.devmaru.xyz와 같이 2차 서브도메인에 대해서는 바인딩이 지원되지 않는다는 점입니다.

주의 2)
ASC는 동일한 구독 내의 다른 App Services에서만 사용할 수 있다. 물론, 구독이 동일하다면 SSL이 발급된 리소스 그룹과 다른 리소스 그룹에서 사용하는 것은 가능합니다.

적절한 인증서 SKU를 선택하고 난 후 약관에 동의하면 다음 단계로 진행할 수 있습니다.

 

3단계 – Azure Key Vault에 인증서 저장

SSL 인증서 구입 완료 후 App Service Certificate 리소스 블레이드를 열어보면 아래와 비슷한 화면을 볼 수 있을 것입니다.

ASC 인증서 속성

상태(Status) 필드를 보면 Pending Issuance(발급 보류 중)로 표기되어져 있는데 이 인증서를 사용하기 위해서는 몇 가지 추가 단계를 완료해야 합니다.
(위 그림은 발급 완료 후에 화면을 캡쳐한 관계로 ‘발급됨’으로 표기되어 있음)
참고) Key Vault는 클라우드 응용 프로그램 및 서비스에서 사용되는 암호화 키 및 비밀을 보호하는데 도움이 되는 Azure 서비스입니다.

단계 1 : 저장(Store)

ASC는 Azure Key Vault Secret을 이용하여 PFX 인증서를 안전하게 저장합니다.
인증서 속성 블레이드 내에서 인증서 구성을 클릭하고 1단계: 저장을 클릭하여 이 인증서를 Azure Key Vault에 저장합니다.
Key Vault 상태 블레이드에서 Key Vault 리포지토리를 클릭하여 이 인증서를 저장할 기존 Key Vault를 선택하거나 새 Key Vault 만들기로 동일한 구독 및 리소스 그룹 내에 새 Key Vault를 만들어야 합니다.
다만,  Azure Key Vault의 경우 이 인증서를 저장하는 데 약간의 별도 요금이 부과되는데 다행히 비용은 저렴한 편입니다. 자세한 비용에 대해서는 아래의 링크를 통해 확인해 보시기 바랍니다.

https://azure.microsoft.com/ko-kr/pricing/details/key-vault/

이 인증서를 저장할 Key Vault 리포지토리를 선택하면 저장 옵션이 표시됩니다.

인증서 저장

단계 2 : 확인(Verify)

ASC를 획득하기 위해서는 입력한 도메인에 대한 소유권 확인 과정을 거쳐야 합니다. 도메인 소유권을 확인하는 데에는 아래와 같이 3가지 방법이 제공되고 있습니다.

  1. Manual Verification
    a. HTML 웹 페이지 확인
    – ”starfield.html”이라는 HTML 파일 만들기
    – 이 파일의 내용은 도메인 확인 토큰의 이름과 정확히 같아야 합니다. (토큰은 도메인 확인 상태 블레이드에서 복사할 수 있음)
    – 이 파일을 도메인을 호스팅하는 웹 서버의 루트에서 업로드합니다. (/.well-known/pki-validation/starfield.html)
    – 확인이 끝났으면 새로 고침을 클릭하여 인증서 상태를 업데이트합니다. (확인을 완료하는 데 몇 분 정도 걸릴 수 있음)
    b. DNS TXT record 확인
    – DNS 관리자를 사용하여 @ 하위 도메인에 값이 도메인 확인 토큰과 같은 TXT 레코드를 만듭니다.
    – 확인이 끝났으면 “새로 고침”을 클릭하여 인증서 상태를 업데이트합니다.
  2. Mail Verification
    도메인 등록 대행 기관으로부터 도메인을 취득할 때 우리는 해당 도메인에 대한 관리용 email 주소를 등록 대행 기관에 제공합니다. ICANN은 인터넷상의 모든 사람이 공개적으로 액세스 할 수 있도록 자신의 데이터베이스에 이러한 전자 메일 주소를 게시합니다.
    ASC RP는 확인 메일을 이 메일 주소들로 보내는 우리는 이 블레이드에서 메일을 보낸 시간과 함께 전송된 메일 주소들의 목록을 확인할 수 있으므로 적절한 메일 주소를 확인해서 작업을 완료할 수 있습니다.
    메일로 도메인 소유권 확인
  3. App Service Verification
    이 방법은 해당 도메인이 하나 이상의 App Service 앱에 사용자 정의 도메인으로 할당되어 있는 경우 사용할 수 있습니다. 만일 지역 분산 앱이라면 하나 이상의 앱을 이 블레이드에서 확인할 수 있습니다.

 

4 단계 – App Service 앱에 인증서 할당

이 단계를 수행하기에 앞서 해당 앱에 사용자 지정 도메인이 이미 할당되어 있어야 합니다. 즉, 웹 앱 생성 후 기본 제공되는 <webappname>.azurewebsites.net 형식의 도메인에는 SSL 인증서를 할당할 수 없습니다.
Azure Portal에서 페이지 왼쪽의 App Service 옵션을 클릭하고 이 인증서를 할당하려는 앱의 이름을 클릭합니다.
설정에서 SSL 인증서를 클릭하고 App Service Certificate 가져오기를 클릭하고 방금 구입한 인증서를 선택합니다.

SSL 인증서 가져오기
할당된 App Service Certificate

SSL 바인딩 섹션에서 바인딩 추가를 클릭하고 드롭다운을 사용하여 SSL로 보안을 설정할 도메인 이름과 사용할 인증서를 선택합니다.
SNI(서버 이름 표시)를 사용할지 또는 IP 기반 SSL을 사용할지 선택할 수도 있습니다.

SSL 바인딩 추가하기

바인딩 추가를 클릭하여 변경 내용을 저장하고 SSL을 사용하도록 설정하면 이 후 해당 웹 앱에 HTTPS를 사용할 수 있습니다.

SSL 바인딩 완료

여기까지 우리는 Azure 웹 앱에 SSL을 적용하는 방법을 알아보았습니다.
다음 포스팅에서는 3rd Party 인증서를 등록하는 방법에 대해서 다루어 볼 예정입니다.

참조
https://docs.microsoft.com/ko-kr/azure/app-service-web/web-sites-purchase-ssl-web-site

 

월요일, 07 8월 2017 / Published in 클라우드 활용팁

Microsoft Azure의 가상머신을 자동으로 종료하기

클라우드에서 다양한 워크로드를 구성하다보면 늘어나는 인스턴스의 수에 따라 비용에 대한 압박을 받을 수 밖에 없습니다. 따라서 클라우드에서 효과적으로 비용을 관리하기 위해서는 불필요한 서비스를 만들지 않고, 사용되지 않는 리소스는 과감히 삭제하는 것이 좋습니다. 클라우드라면 언제든지 우리가 원하는 리소스를 만들고 사용할 수 있기 때문이죠. 하지만 매일 사용하지는 않지만 자주 사용되는 서버라면 “삭제”하지 않고 “중지”하는 것만으로도 충분히 비용을 절감할 수 있습니다. 예를 들면 업무가 종료되는 오후 09:00에는 서버를 중지시켜서 불필요한 비용을 줄일 수 있습니다.

Microsoft Azure 는 가상머신을 자동으로 종료할 수 있는 기능을 제공하고 있습니다. 첫번째 방법은 Runbook을 사용한 “Azure Automation” 기능을 사용하는 것이고, 두번째 방법은 Azure Portal의  “자동종료” 기능을 설정하는 것입니다. 여기서는 별도의 스크립트 작성이 필요없고 손쉽게 가상머신을 종료할 수 있는 Azure Portal의 기능을 설명하겠습니다. 혹시 Runbook을 이용한 Automation Script 작성 방법이 궁금하신 분은 Automation의 업무 시간 외 VM 시작/중지 를 참고하세요~

[가상머신 자동 중지를 위한 포탈기능 사용]

Azure Portal 로그인

 

 

 

 

 

 

 

 

 

  • 자동종료 기능 설정

자동종료 설정

우선 자동종료를 설정하고하하는 가상머신을 선택하면 속성 메뉴에서 “자동종료” 메뉴가 보입니다. “자동종료” 메뉴에서 사용을 “설정”으로 선택하면 예약된 종료 시간을 설정할 수 있습니다. 주의 점은 위 캡쳐화면에서 보이는 바와 같이 표준시간대를 UTC+09:00 Seoul로 설정해야 한국시간 기준으로 자동 종료가 예약됩니다.

[추가 팁]

Azure Portal의 자동종료 기능을 설정할때 Webhook을 이용하면 지정한 시간에 중지된 가상머신을 자동으로 실행할 수도 있습니다. (웹훅을 이용한 자동실행 기능은 다음에 설명하겠습니다.)

이상 간단하지만 활용도는 매우 높은 가상머신을 자동으로 종료하기 팁을 공유드렸습니다.

 

 

월요일, 31 7월 2017 / Published in 클라우드 활용팁

Azure 를 이용한 서버 장애 파악 방법

서버 장애가 발생했을 때 서버 관리자 혹은 개발자가 먼저 발견하여 고객이 장애를 알아차리기 전에 조치한다면 아무 문제 없겠지만, 대부분의 서버 장애는 예기치 못한 상황에 발생하여 고객으로부터 문제를 전달받는 경우가 많습니다.

이러한 서버 장애를 모니터링 할 수 있는 여러 가지 유료, 무료 서비스가 있지만 그 중에서도 Azure 클라우드 환경에서 모니터링 서비스를 이용하는 방법을 소개하겠습니다.

 

Azure Function 을 이용한 서버 장애 확인

Azure Function은 서버를 사용하지 않고 간단한 코드나 함수를 실행할 수 있는 솔루션입니다. C#, Node.js, Python, PHP 등 다양한 개발 언어를 지원하고 사용하는 시간만큼 소량의 비용을 지불하면 됩니다.

자세한 내용은 Azure Function 을 참고하시면 됩니다.

Azure Function을 이용해 서버 장애를 확인하는 방법은 Function에서 Url을 호출하여 response 상태에 따라 로그를 남기거나 메일을 발송하는 추가 조치를 구현하는 것입니다.

제가 사용한 방법은 Node.js를 이용하여 urlStatusCode API를 활용하여 response 코드값에 따라 추가 조치를 할 수 있도록 하였습니다.

const urllist = [‘testurl.com’];   -> 서버url 정의

module.exports = function (context, myTimer) {

const timeStamp = new Date().toISOString();

const urlStatusCode = require(‘url-status-code’)  -> 서버 response code값

 

for (var i = 0; i < urllist.length; i++) {

urlStatusCode(urllist[i], (error, statusCode) => {

statusCode = ” + statusCode;

var checkStatus = statusCode.substring(0,1);

if (checkStatus == ‘4’ || checkStatus == ‘5’) {

                추가 조치 넣을 부분

 

} else {

context.log(statusCode)

}

});

}

context.done();

};

 

위의 코드를 Azure Function에 등록하여 Crontab 스케쥴러를 이용해 주기적으로 서버의 response를 받아와 상태를 점검하게 됩니다. 후속조치 부분에는 메일을 이용한 알림이나 장애 로그를 기록하는 등 개발자가 원하는 로직을 구현하면 됩니다.

Azure의 경고 규칙을 이용한 서버 장애 확인

Azure의 경고 규칙은 Azure의 Iaas환경이나 Paas환경의 서버에서 사용할 수 있는 기능입니다. 서버의 설정 부분에서 경고 규칙 메뉴를 통해 쉽게 설정할 수 있습니다.

Azure의 경고 규칙을 이용한 서버 장애 확인위의 화면은 실제 Iaas 환경의 서버에서 규칙을 추가하는 화면입니다. 설정한 조건에 따라 임계치를 정해 정한 값보다 작거나 클 경우 알림을 설정할 수 있습니다.

기본으로 제공하는 알림은 메일서비스 이고 추가로 문자나 다른 알림서비스는 사용자가 직접 연결하거나 Azure Function을 통해 연결하면 됩니다.

Azure 의 경고 규칙을 이용한 서버 장애 확인 - 문자 이메일 알림

조건 설정을 하는 부분은 Iaas VM이나 Paas 웹앱, Database 에 따라 세부적으로 나누어져 있어 사용자가 원하는 경고를 설정할 수 있습니다.

기본 알림은 메일뿐만 아니라 Azure Runbook 이나 Logic App을 통해 추가 작업을 할 수 있습니다. Runbook은 Windows Powershell기반으로 자동화된 프로세스를 수행할 수 있도록 도와줍니다. 경고가 발생하면 해당 리소스를 정지하거나 재시작 하는 등의 추가 조치를 취하도록 프로세스를 구성할 수 있습니다.

Logic App은 복잡한 Work Flow를 쉽게 구성할 수 있도록 해줍니다. 이 Logic App을 이용하여 경고 발생 시에 문자를 전송하거나 SNS에 알림을 주거나 하는 프로세스를 구현하여 기본메일에서 추가된 알림을 설정 할 수 있습니다.

 

 

Azure Application Insights의 가용성 테스트를 이용한 서버 장애 확인

Application Insights는 여러 플랫폼의 개발자를 위한 확장 가능한 응용 프로그램 성능 관리 서비스 입니다. 다양한 모니터링을 통해 장애를 빠르게 진단하여 원인을 분석할 수 있습니다. 그리고 여러 개발 도구와 연결 지점도 가지고 있습니다.

Azure Application Insights의 가용성 테스트를 이용한 서버 장애 확인

Application Insights의 가용성 테스트를 이용하면 서버의 상태를 확인 할 수 있습니다.

확인하고자 하는 서버의 url을 일정시간마다 호출하여 HTTP의 응답이 정해진 기준에 미치지 못하면 지정된 관리자에게 메일을 통해 장애 메시지가 보내지게 됩니다.

Application Insights의 장점은 서로 다른 5군데의 지역에서 설정한 url을 호출하여 장애를 확인하기 때문에 다른 방법에 비해 정확한 장애 여부를 파악할 수 있는 것 입니다.

각 방법 별 요금 및 기능 비교

먼저 첫 번째 방법인 Azure Function의 경우는 사용자가 직접 개발을 해야 하고, 알림도 사용자가 직접 연결을 해야 한다는 특징이 있습니다. 직접 개발하는 만큼 사용자가 원하는 기능을 구현하여 이용할 수 있겠지만 개발 시간이 소요되는 단점이 있습니다. 비용은 사용한 양 만큼 청구되는 방식입니다.

두 번째는 Azure 경고 규칙을 이용한 방법으로 Azure 리소스를 지정하여 사용자가 정한 조건이 임계치를 벗어나면 알림이 오게 되는 간단한 방법이지만 실제 이용 시에 서버 장애가 아님에도 네트워크나 회선 문제 등으로 인해 문제로 인식하는 경우가 있습니다. 사용 비용은 무료입니다.

세 번째는 Application Insights의 가용성 테스트를 이용한 방법인데 점검하고자 하는 서버의 url을 등록하면 사용자가 지정한 장소에서 서버에 ping을 보내 response를 받아 상태를 확인하는 방법입니다. 요금은 무료로써 Azure 리소스에 해당하는 서버만 점검하는 것이 아닌 url주소에 따라 장애 여부 판단이 가능합니다.