728x90
 

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4

AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라 단가가 매겨지고 (=TTL조정으로 어느정도 비용 통제도 할..

ondemand.tistory.com

지난 글에서는 Route53 로그 추출을 위한 사전 작업으로 Route53의 대상 Hosted Zone에 Query Logging을 설정하고 CloudWatch Logs로 로그를 전송하도록 구성을 했습니다. 로그가 정상적으로 CloudWatch Logs로 수집되기 시작했기 때문에, 이번 글에서는 `Subscription filters`를 생성하여 <로그를 구독할 서비스를 설정>하고 CloudWatch Logs의 로그를 해당 서비스가 구독하도록 하겠습니다.

다만 이 작업을 진행하기 전에 Amazon ElasticSearch를 향한 `Subscription filters` 생성시 입력해야 하는 ElasticSearch Cluster 도메인을 먼저 만들고, 해당 도메인을 filter에 지정하는 작업을 해보도록 하겠습니다. 참고로 CloudWatch Logs에서 생성할 수 있는 filter는 4가지 정도가 있습니다만 AWS ElasticSearch로 전송하는 것이 가장 간단합니다. 

(Update 2022.04.21)

AWS의 제품 라인업에서 ElasticSearch가 빠지고 Amazon OpenSearch로 대치되었습니다.
ES의 오픈소스 버전이라고 생각하면 되기 때문에 기본적으로 큰 차이는 없습니다!

 

 


 

Amazon Elasticsearch Cluster 생성하기

`Elasticsearch subscription filter`를 설정하기 위해서 AWS Web Console 에서 `Amazon Elasticsearch`를 선택하고 관리 화면으로 이동하도록 하겠습니다. 제가 사용하는 Account에는 생성된 ES Cluster가 없기 때문에 아래 화면과 같습니다만, 미리 생성되어 있거나 사용중인 ES Cluster가 있다면 목록에 해당 클러스터의 이름이 보일것입니다.

어쨌든 우리는 새로운 클러스터를 만들어야 하기 때문에 `Create domain`을 눌러 새로운 ElasticSearch Amazon OpenSearch Cluster를 구성해 보도록 하겠습니다. 새로운 클러스터 생성시 `도메인`을 지정하게 되고, 이후 CloudWatch에서 subscription filter를 설정할 때도 생성한 도메인 이름을 선택하게 됩니다. 

간단하게 짧은 시간동안 Route53 DNS의 로그를 수집하여 분석해야 하거나 로그 양이 많지 않은 경우라면 클러스터에 사용되는 리소스 규모를 적당한 크기로 선택하는 것이 좋습니다. ElasticSearch 생성의 첫 단계에서 `Development and testing` 타입으로 클러스터를 생성해도 무방할지 생각해 보시기 바랍니다. 설명에 따르면 이 옵션을 쓰면 AWS Region의 가용성 영역을 하나만 사용하게 되고 HA(High Availability)를 보장받기 힘듭니다. 그럼에도 불구하고 우리는 공부를 하는 중이니 간단하게 클러스터를 구성하도록 하겠습니다.

 

 

 

두번째 화면에서는 할당될 Elasticsearch 클러스터의 도메인(Domain)으로 사용할 키워드를 입력합니다. 앞서 이야기 한 것처럼 여기에서 입력한 키워드를 클러스터 선택시 사용하게 됩니다. 이외에도 자동 튜닝, 인스턴스 타입, 스토리지 크기 등을 정하게 됩니다만 크게 필요가 없다면 옵션을 끄는 것이 비용 관점에서 유리합니다. 물론 성능이 좋은 ES 클러스터를 만들어야 한다면 세세하게 설정을 손봐야 하겠지만 일단 로그를 흘리면서 ES로 던지고, ES와 함께 제공되는 Kibana에서 조회해 보는 것이 목적이니 기본 값으로 시험해 봐도 무방하다.

 

 

(Update 2022.04.21)

Amazon OpenSearch 로 제품이 변경되면서 설정 화면이 약간 바뀌었습니다.
아래와 같이 `Deployment type` 선택이 약간 아래로 밀렸고 Name 지정을 먼저 하도록 바뀌었습니다.
순서만 약간 바뀌었을 뿐, 입력하고 선택하는 내용은 대부분 큰 변경이 없습니다.

1.
먼저 Domain Name과 Deployment Type을 선택합니다.
시험중이라면 `Development and testing`을 선택하여 단일 리전에만 배포합니다.




 

다음으로 ES와 Kibana에 접근할 수 있는 접근 권한을 설정해야 합니다. VPC내에서만 접근 가능하게 하거나 Cognito 등을 연동하여 IAM 기반으로 접근할 수 있도록 하는 것이 좋습니다만 시험을 위해서 Public Access로 구성을 진행하고 <Fine-grained access control> 섹션에서 `Create master user`를 눌러 단순하게 ID, Password로 접근하게 하는 방법을 써도 무방합니다. Production용 시스템을 구성한다면 이렇게 구성하지 않는 것이 Job Security에 유리하겠습니다 :-)

 

 

(Update 2022.04.21)

시험적으로 만들어보는 중이니 `Network`는 `Public access`로
`Fine-grained access control`도 `Create master user`를 이용하도록 합시다.
이전 버전과 큰 차이는 없습니다. 




`Access Policy` 역시 단순한 시험을 위해 IP ACL로 설정해 보았습니다. 

이후 AWS의 꽃 중 하나인 Tag 설정 단계가 있지만 시험용 설정을 위해서는 굳이 설정하지 않아도 됩니다. 마지막으로 `Review` 단계에서 입력한 값들을 한번 더 검증하고 문제가 없다면 `Confirm` 버튼을 눌러 ElasticSearch Cluster 생성을 마무리 하도록 하겠습니다.

늘 느끼는 것이지만 AWS를 비롯한 Public Cloud에서는 이것 저것 설정하고 준비해야 할 것들이 꽤 많습니다. 이어지는 글들에서는 CloudWatch Logs에서 Subscription filter를 생성하고 IAM에서 필요로 하는 권한을 설정하는 작업을 진행하도록 하겠습니다. 

 

(#3/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확

ondemand.tistory.com


AWS 입문자라면 AWS 자격증 공부를 통해 체계적으로 전반적인 AWS 에코시스템을 학습하는 것이 좋습니다. udemy 베스트셀러 강의를 통해 자격증과 AWS 지식을 함께 쌓아보시면 어떨까요?

 

[NEW] Ultimate AWS Certified Cloud Practitioner - 2021

Pass the Amazon Web Services Certified Cloud Practitioner CLF-C01 exam, Practice Exams included with explanations!

www.udemy.com

 

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

728x90
728x90

서비스를 제공하는 사람과 회사는 늘 악의적인 해커의 공격으로부터 서비스 인프라와 사용자들을 지켜야 하는 숙제를 안고 있습니다. 우리 회사의 웹 사이트는 안전한지, 공격이 발생했을 때 어떻게 사용자 정보를 보호할 것인지, 그리고 공격이 지속되는 상황에서 어떻게 서비스를 지속적으로 제공할 수 있도록 할 것인지에 대한 고민을 해야만 합니다. 세계 최대 CDN 공급 사업자인 아카마이(Akamai)는 이런 고민들 중 "지속적인 서비스의 제공" 관점에서 DDoS 공격 발생시 그 여파를 경감시킬 수 있는 보안 사업자를 선택하는 4가지 포인트를 인포그래픽으로 정리하여 공개했습니다.





#1. 위협에 대한 뛰어난 지식을 보유하고 있는가? (Maximal Threat Intelligence)


IT 기술이 발달하는 것과 보조를 맞추어 해커들의 공격 기술도 더욱 정교하게 바뀌고 있습니다. 다양한 계층에서의 공격 (e.g. OSI 7 Layer) 은 물론이고 서비스 인프라의 취약점을 발빠르게 캐치하여 진행하는 공격 등 해커들의 수준이 점점 높아지고 있습니다. 따라서 보안 사업자를 선정함에 있어 이러한 최신의 공격을 잘 이해하고 있는지, 그리고 어떻게 방어해야 할지를 알고 선제적인 조치를 취해줄 수 있는지를 검토해야 한다고 아카마이는 이야기하고 있습니다.





#2. 얼마나 많은 공격을 막아본 경험이 있는가? (Most Front-Line Experience)


음식도 많이 먹어본 사람이 맛집을 잘 찾는 것처럼 해커들의 공격 역시 많이 경험하고 막아본 사업자만이 잘 막을 수 있다는 것은 당연한 사실입니다. 하드웨어 기반의 DDoS 어플라이언스를 도입할때도 늘 중요하게 평가되는 것이 얼마나 많은 기업들이 장비를 도입 했고 사용하고 있는가 입니다. 시대가 클라우드 세상으로 바뀌면서 하드웨어 어플라이언스를 도입하는 것보다는 플랫폼을 이용하면서 플랫폼이 제공하는 방어 도구를 이용하는 경우가 많아지고 있습니다. 아카마이라던가 아마존처럼 글로벌 클라우드 인프라를 운영하는 회사들은 아무래도 이런 부분에서 경험치가 높을 수 밖에 없을 것 같습니다.





#3. 다양한 방법을 이용하여 DDoS 를 경감시킬 수 있는가? (Best Mitigation Capabilities)


해커들의 공격은 매년 규모가 더 커지고 있습니다. 제로데이 취약점을 이용하여 미처 보안 업체들이 패턴 업데이트를 하거나 취약점에 대한 패치가 공급되기 전에 공격이 시작되는 경우도 많습니다. 이런 공격들이 발생했을 때 얼마나 효과적으로 다양한 방법을 이용해서 DDoS 공격을 경감시키고 막을 수 있을 것이냐는 중요한 포인트입니다. 웹 방화벽으로 불리우는 7계층의 WAF 에서부터 IP / TCP 계층에서의 공격 등 다양한 형태의 공격을 대응 하나의 플랫폼으로 대응할 수 있는 기업은 아직 많지 않은 것 같습니다.





#4. DDoS 경감을 위한 인프라의 가용량이 충분한가? (Global Mitigation Capacity)


DDoS 공격이 무서운 것은 서비스 인프라의 자원이 정상적인 서비스를 할 수 없도록 만들기 때문입니다. IT 인프라의 수준이 발달하는 만큼 DDoS 공격의 규모가 커지는 것은 서비스 불가 상태를 만들기 위해 더 많은 공격 자원이 필요하다는 것과 일맥상통하는 부분입니다. 결국 그러한 공격을 받아낼 수 있는 인프라, 플랫폼을 가지고 있지 않은 사업자는 DDoS 에 대한 대비책으로 선택하기는 어려워 보입니다. 순간적으로 수백기가 혹은 테라급의 트레픽이 몰려왔을 때도 문제 없는 플랫폼을 가진 사업자의 선정이 중요한 포인트라 하겠습니다!





서비스를 기획하고 준비하는 단계에서부터 바야흐로 글로벌을 생각해야만 하는 시기입니다. 이는 언제든 대규모의 공격이 발생할 수 있고 이에 대한 대비도 같이 해야한다는 것을 의미합니다. 아카마이, 엣지캐스트, 아마존, 애져 등 많은 클라우드 사업자들은 근래에 보안에 대한 많은 상품과 전략을 발표하고 있습니다. 이는 고객들의 니즈가 보안에 많다는 것을 의미하고 이를 잘 처리할 수 있는 기업이 또 한번의 플랫폼 전쟁의 승자가 될 수 있다는 것을 암시합니다. 여러분의 선택은 어떤 플랫폼인가요...?





728x90
728x90

개발자로 일을 하다보면 개인적으로 사용할 수 있는 테스트 서버가 필요할 때가 많습니다. 회사에서 제공되는 개발 머신이 있는 경우가 많겠지만 왠지 좀 비밀스러운 일도 하고 재미있는 구성들을 해보기 위해서 별도로 서버를 준비하고 싶을때가 많지요. DDNS(Dynamic DNS) 서비스를 이용해서 집에 PC 나 소규모 서버를 구성하는 것도 방법이겠습니다만 전기세나 DDNS 의 잘못된 동작, 행여나 있을지 모르는 대역폭(Bandwidth) 이슈가 걱정되는게 사실입니다.


하지만 아마존 EC2 와 같은 클라우드는 좋긴 하지만 가격이 생각외로 좀 쎈편이라 (게다가 콘솔이 온통 영어고 해외 사용료 결재 등이 왠지 또 찜찜한 분들도 계실거구요) 저렴한 웹 호스팅을 쓰는 경우가 생기곤 합니다. 하지만 호스팅은 서버 전체를 제어할 필요가 있는 경우, 혹은 특정한 모듈, 설정을 하고자 할때 그닥 좋지가 않죠. 하지만 물리 장비를 이용한 서버 호스팅은 가격이 만만치 않은게 현실입니다.




이런 생각을 똑같이 하시고 계시던 분이 있다면 가비아(gabia)가 12월 한달동안 진행하는 클라우드 서버 기본상품(g클라우드 베이직?) 70% 할인행사를 이용해 보시면 어떨까 싶습니다. 1vCore 에 메모리도 고작 1GB, 스토리지도 100GB 밖에 안된다고 생각할 수 있지만 공인IP 를 확보할 수 있고 트레픽도 가상머신당 1TB 까지 별도 과금이 없으니 간단하게 서버를 구성하고 돌리는데 무리가 없어 보입니다.


행사 내용을 살펴보면 12월 한달간 가입하는 신규 고객에 한정되고 1인당 2개의 가상머신까지만 혜택을 받을 수 있다고 합니다. 그리고 70% 할인된 금액으로 과금되는 것은 2개월 적용되고 이후에는 다시 원래의 가격 25,000원/월 로 전환되는 것으로 보이네요. 제약조건이 있긴 하지만 클라우드 서비스들에 비해 단기 사용을 생각하면 무척 좋은 가격입니다. 부가가치세 별도라는 조항이 있지만 두달동안 16,500원으로 가상머신을 쓸 수 있는 기회이니 필요하신 분들은 이용하시면 좋을 것 같네요!




가비아(gabia)의 클라우드 호스팅 70% 할인행사 자세히 살펴보기 [바로가기]


728x90
728x90

어제 낮에 간만에 마이크로소프트 애져(Azure)에 관한 웨비나(Webinar)를 시청했습니다. 강사로는 마이크로소프트 클라우드 솔루션 아키텍트(Cloud Solution Architect)로 활약중이신 이정훈 님이 나오셨습니다. 애져에 대한 깊은 내용 보다는 전반적인 최근의 업데이트, 변화를 훑어보고 다른 아마존 웹 서비스(AWS, Amazon Web Services)와 같은 다른 서비스와 비교하는 내용들이 많이 나왔던 것 같습니다 (질문 시간에...)


마이크로소프트가 제공하는 링크를 통해서 발표자료를 받으셔도 되구요(https://azureinfo.microsoft.com/rs/microsoftdemandcenter/images/AP-Azure-WBNR-FY15-11Nov-KO-IaaS-Part1.pdf) 본 포스팅에 참조로 추가된 발표자료를 받으셔도 됩니다. 애져에 대한 전반적인 내용을 머릿속에 담고자 하시는 분들에게 도움이 많이 될 자료인 것 같습니다





728x90

+ Recent posts