728x90

지난주 후반부, 한국 뿐만 아니라 전세계가 시끌시끌했습니다. 
사실상의 서버측 로깅 표준으로 자리잡힌 log4j 로깅 모듈의 보안 취약점이 발견되었고
공격방법이 인터넷에 고개되면서 Zero Day Vulnerability 가 발생했기 때문입니다.

대략 이런 흐름! (출처 : CloudFlare Blog)

 

취약점을 간단히 요약하자면,
"로그로 기록되어야 하는 문자열에 악의적인 내용을 집어넣어 원격지에서 서버의 코드, 명령을 실행할 수 있는 취약점이 있었음"
입니다.

취약점을 통해 외부에 노출되지 않은 LDAP 서버 등으로 악의적인 코드가 담긴 자바 클래스를 전송하고 
log4j 를 통해 이 클래스를 메모리에 로딩하는 방식으로 서버에 침투하게 됩니다. 
이번 취약점은 오래전 SSL 프로토콜의 취약점으로 명성을 날렸던 하트블리드(heartbleed)급으로 알려졌습니다.

패스틀리 블로그의 이 정리가 가장 깔끔하고 명료합니다!


취약점에 대한 대응은 크게 두가지 방식으로 진행되었습니다. 
1. 취약점이 패치된 log4j 가 배포되기 전까지는 코드 인젝션이 발생할 수 있는 JNDI 의 옵션을 끈다
2. 취약점 패치 버전 (2.15.0+) 가 배포된 후에는 새로운 log4j 로 교체한다

이런 대응이 여러 회사의 개발조직 중심으로 대응되는 동안 
물들어올때 노를 저어야 한다는 것을 잘 알고 있는 클라우드 벤더들은 
열심히 관련된 포스팅을 날리며 자사의 보안 솔루션들을 홍보하기 시작했습니다. 

클라우드 플레어

 

아카마이

 

패스틀리

 

아마존

 


간만에 글로벌 초대형 급의 취약점으로 주말이 시끌시끌 했습니다. 
아직까지 취약점은 현재 진행형이기 때문에 두눈 부릅뜨고
log4j 를 쓰는 곳이 없는지 살펴봐야 하겠습니다!

728x90
728x90

세계적으로 클라우드 서비스를 제공하는 사업자들은 무척 많습니다. 각 사업자들은 각자의 컨셉과 목표를 가지고 클라우드 서비스를 만들고 제공하고 있는데요 아마존의 AWS, 마이크로소프트의 애져(Azure) 등이 대표적입니다. 아마존의 경우 인프라스트럭쳐(IaaS)에 대한 가상화와 클라우드화를 기치로 내걸고 사업을 시작하여 지속적으로 플랫폼의 영역(PaaS)으로 올라오는 중이며 마이크로소프트의 경우 개발자들이 보다 쉽게 개발된 서비스와 코드를 사용자에게 제공할 수 있도록 플랫폼에서 시작하여 인프라스트럭쳐의 영역으로 내려오는 전략을 가져가고 있습니다.


마이크로소프트는 자사의 제품들을 전반적으로 실물 제품에서 가상의 제품, 클라우드화를 지속적으로 진행하고 있기 때문에 이의 연장선상에서 애져의 시장 전략을 가져가고 있습니다. 엊그제 진행된 애져컨(Azure Con)의 키노트에서 마이크로소프트가 꿈꾸는 클라우드 서비스와 방향성을 볼 수 있는 좋은 내용들이 무척 많이 나왔습니다. 그 중에서도 가장 눈에 띄는 것은 아무래도 컨텐츠 전송 부문에서의 협력을 글로벌 CDN 1위 사업자인 아카마이(Akamai)와 한다는 발표가 아닐까 싶습니다.






키노트 세션이었기 때문에 기존의 CDN 을 유지하면서 아카마이의 글로벌 foot-print 를 활용하는 전략인지 아니면 기존의 협력관계였던 EdgeCast 와의 관계를 청산하고 아카마이를 전면에 내세우는 것인지는 자세히 소개되지 않았습니다. 다만 올해 하반기 까지는 제한적으로 고객들을 선별하여 애져 플랫폼 및 상품들과 아카마이를 통한 CDN 을 구현하는 작업을 진행하는 것으로 보이며 일반 고객들이 쓸 수 있는 GA (General Availability)는 내년 초가 되어야 할 것으로 보입니다.





마이크로소프트와 아카마이는 9월 29일 화요일 나란히 이러한 협력관계가 시작되었음을 알리는 공식 블로그 포스팅을 공개했습니다. 클라우드 환경으로 컴퓨팅 자원을 제공하는 회사들, 그 회사들의 서비스를 이용하는 고객들의 공통적인 고민은 "어떻게 글로벌 엔드유저들에게 전송을 빠르게 할 수 있을 것인가?" 입니다. 컴퓨팅 자원을 여러 리전(Region)에 나누어 서비스 하는 것은 쉬운 접근이겠지만 이들의 관리와 형상 유지, 라스트 마일(Last Mile)구간에서 발생하는 속도 이슈에 대한 해결은 쉽지 않은 문제입니다.


이를 위해서 아마존은 클라우드 프론트(Cloud Front)라는 자체 CDN 서비스를 제공하고 애져는 CDN 사업자와의 제휴를 통해 이를 해결하는 비즈니스 모델을 가지고 있습니다. 어떤 접근이 맞고 틀리는지, 혹은 더 좋고 나쁜지는 상황에 따라 다르겠지만 마이크로소프트 애져가 글로벌 1위 사업자인 아카마이와 제휴하여 서비스를 제공하는 것이 더 나은 모델이지 않나 하는 생각이 듭니다.





728x90
728x90

웹 사이트를 만들때 가장 많이 손이 가는 부분이 어딜까요? 아마도 동일한 원본 이미지를 가지고 다양한 사이즈로 변조하는 작업에 많은 공수가 들어가실 겁니다. 이는 비단 이미지에 대한 변조 공수 뿐만 아니라 이후 유지보수와 관리의 관점에서도 많은 이슈를 낳곤 합니다. 반응형 웹 시대에 미디어 쿼리를 이용하여 뷰포트에 맞는 이미지를 내려주는 것은 필수이다보니 손을 놓고 있을 수도 없는 계륵(?)처럼 느껴지시는 분도 많을 것 같습니다. 물론 아카마이(Akamai)와 같은 컨텐츠 전송 네트워크 사업자에서 제공하는 Front End Optimization 기술을 이용하면 편리하게 실시간 변환이 가능하지만 간단하게 소규모로 서비스를 기획하는 단계에서는 이 역시 쉬운 선택이 되기는 힘듭니다.


오늘 소개해 드리는 TinyPNG 라는 서비스는 API 기반으로 실시간 PNG/JPG 이미지에 대한 가공을 제공하는 곳으로 HTTP 기반의 웹 서비스이다보니 사용하기도 편리하고 비용도 그리 비싸지 않아 연동에 대한 설계만 잘 해두면 쏠쏠하게 이용해볼 수 있는 서비스가 될 것 같습니다. 첫 500개의 이미지 변환에 대해서는 별도 비용이 발생하지 않고 간단히 HTTP 기본 인증 (Basic Authentication) 으로 구성되어 curl 명령만으로도 쉽게 테스트 해보실 수 있습니다. 이마저 번거로운 분들을 위해 간단히 계정을 만들어 시험을 해봤습니다.


TInyPNG 웹 사이트 바로 방문해보기 [바로가기]




귀엽게 생긴 곰 녀석(?)이 맥북을 들고 작업하는 모습이 인상적인 TinyPNG 의 첫 페이지 입니다. 화면의 하늘색 박스에 이름과 이메일 주소만 넣으면 바로 API Key 를 발급받을 수 있는 링크를 메일로 전송해줍니다. 메일로 전달받은 링크를 클릭하면 인증이 완료되며 API Key 와 무료로 사용할 수 있는 이미지 갯수 등이 표시된 페이지로 연결됩니다. 물론 상용으로 등록하고 싶은 분들을 위해 결제정보를 입력할 수 있는 화면도 친절하게 연결되어 있습니다.





화면 가운데 커다랗게 표시된 API Key 는 Basic Authentication 방식의 해싱 값으로 사용될 데이터입니다. ID / PWD 를 이용하지 않고 바로 해싱된 값이 있다는 것은 그냥 헤더에 해당 값이 들어가면 된다는 이야기와 동일하겠죠? 이제 간단하게 curl 을 이용해서 변환을 테스트 해보겠습니다. 왠지 JPEG 는 스펙상 사이즈 조절 등이 쉬울 것 같아 일부러 PNG 파일을 하나 받아서 테스트를 해봤습니다. 잡스옹, 저의 모르모트가 되어주실거죠? ㅇ9응??)




https://api.tinify.com/shrink 주소로 변환할 파일을 업로딩 하면 TinyPNG 에서 파일을 변조한 뒤 변환된 정보와 다운로드 받을 수 있는 경로정보를 JSON 형태의 응답으로 받게 됩니다. 이유는 알 수 없지만 첫번째 리사이즈 시도의 결과물은 두번째 리사이즈 파일과 용량도 동일하고 모든 조건이 같았는데 이상하게 열리지 않더군요. PNG 헤더 등을 점검하는 것은 다소 귀찮아 다시 curl 을 통해 동일한 용량의 동일한 파일을 다운로드 받아 정상적으로 용량이 작게 변경된 것을 확인했습니다. 글을 적으면서 보니 첫번째 시도는 129942 바이트로 JSON 에 기술된 129526 바이트보다 큰 파일이 저장 되었네요. 다시 디렉토리 조회를 해보면 129526 바이트의 정상적인 파일이 내려온 것이 확인됩니다. API 이용시 2차 검증용으로 용량에 대한 확인을 하면 확실할 것 같네요!




단순히 용량을 줄이는 것 이외에 사이즈의 조절 (Crop 등) 에 관한 여러가지 API 옵션이 제공되고 있으며 API 호출시 JSON 형태로 구성하여 Body 영역에 전달하면 됩니다. GET 요청을 하면서 Body 에 정보를 담아 보내는 것이 표준에는 어긋나는 것 같습니다만 일단 TinyPNG 에서는 정상적으로 응답하고 있으니 참고하시기 바랍니다! 이미지 변조가 많은 계절, TInyPNG 등의 서비스로 간단한 이미지 변환은 쉽게 해보시는 것도 관리, 유지보수를 위한 좋은 선택이 될 것 같네요!





728x90
728x90

대규모의 사용자 트레픽을 소화하기 위해서는 고민해야 할 것들이 많습니다. 서비스 오리진(Origin) 인프라의 유연함과 적절한 스토리지(Storage)을 확보해야 하는 것은 물론이고 갑작스런 사용자 폭주에 대비하여 충분한 대역폭(Bandwidth)도 갖추어야 합니다. 큰 규모의 기업이라면 그나마 이러한 준비를 하기 위한 투자(CapEx)가 가능하겠지만 작은 규모의 기업(SMB, SOHO)이나 스타트업(Start-up)이라면 열악한 인프라를 이용하여 서비스를 시작하는 경우가 많습니다.


하지만 충분한 재원을 이용하여 인프라를 증식(?)하는 방법은 한계가 있습니다. 가장 단적인 예는 "충분한 대역폭" 에서 찾을 수 있습니다. 갑작스런 서비스의 인기몰이나 이슈가 생겼을 때 폭주하는 사용자 트레픽은 그 규모를 가늠하기가 힘듭니다. 또한 일시적으로 발생하는 이런 스파이크(Spike)를 대비한다고 평상시에 이용되지 않는 대역폭을 계약하여 사용하는 것은 운영 비용(OpEx) 관점에서 효과적이지 않습니다. 그렇다면 이런 문제는 어떻게 해결할 수 있는 것일까요?





흔히 컨텐츠 전송 네트워크(Content Delivery Network, CDN)이라 불리우는 서비스들이 그 해답이 될 수 있습니다. 글로벌 1위 사업자인 아카마이(Akamai)를 비롯하여 최근에는 아마존(Amazon)이나 마이크로소프트 애져(Azure) 등 클라우드 서비스들도 필수적으로 CDN 서비스를 제공하고 있습니다. CDN 전문 사업자들 뿐만 아니라 클라우드 인프라를 제공하는 사업자들까지 CDN 상품을 내놓고 있다는 것은 인프라와 전송 네트워크의 조합이 대규모의 사용자 트레픽을 소화하기 위해서 필수라는 의미로 해석해도 크게 틀리지 않다는 이야기입니다.


아카마이는 최근 마이리틀텔레비전의 컨셉으로 마이리틀CDN 이라는 인터렉티브 세션을 운영하고 있습니다. 다음주 화요일인 9월 22일 오후에 한시간동안 CDN 의 기본적인 동작 원리와 어떻게 활용하면 도움이 될지에 대한 프로그램이 방송될 예정이라고 합니다. CDN 서비스를 제공하는 사업자들 별로 저마다의 특징과 차별화 포인트를 가지고 있지만 기저에 깔려 있는 기본적인 스킴은 어느정도 비슷하기 때문에 CDN 에 대한 기본적인 소양을 쌓고 글로벌에서 성공할 미래의 내 서비스를 위해 지식의 폭을 넓힐 수 있는 기회가 될 수 있을거란 생각이 듭니다!


아카마이 마이리틀CDN - "CDN의 원리와 활용 기본" 무료 사전등록 [바로가기]



728x90

+ Recent posts