cozyboy

웹(WWW)이 대중화되고 많은 프로그램들이 웹으로 넘어오면서 웹 보안의 중요성은 날이 갈수록 강조되고 있습니다. 웹은 타 인터넷 네트워크 프로토콜에 비해 상대적으로 안전하다고 인식되기 때문에 일반적으로 서비스 포트(80)가 열려있으며 다양한 웹 어플리케이션이 동작하고 서비스됩니다. 그러다보니 웹을 통한 네트워크 취약점 또한 많이 연구되고 있으며, 악의적인 목적을 가진 임의의 공격자 역시 예전의 다양한 네트워크 프로토콜에 관련된 것보다는 직접 웹 어플리케이션의 취약점을 노리는 경우가 많습니다. 

따라서, 웹어플리케이션을 구현할 때는 보안에 보다 더 주의해야 합니다. 국제 웹 보안 표준기구인 OWASP에서는 주기적으로 보안 10대 취약점을 발표하는데, 이 내용을 기준으로 자신의 웹 어플리케이션에 취약점이 없는가 점검하는 일은 매우 중요합니다.

OWASP 2007 Top 10 에 의하면 다양한 취약점들이 보고되고 있는데(조만간 2010년 Top 10이 발표될 듯 합니다), 그 가운데 매우 중요한 보안요소임에도 불구하고 많은 부분 신경쓰고 있지 못하는 취약점이 바로 CSRF 취약점입니다. 

CSRF(Cross-site Request Forgery, 크로스사이트 요청 위조) 공격은 원클릭 공격, 사이드 재킹, 세션 라이딩 등으로도 알려져 있고, 약어로는 XSRF로도 알려져 있습니다. 이 공격은 사이트가 신뢰하는 사용자를 통해 공격자가 원하는 명령을 사이트로 전송하는 기법을 사용합니다. 공격이 사용자를 통해 이루어지기 때문에 공격자의 IP는 추적 불가능한 특성이 있습니다. 

은행사이트를 예를 들자면, 공격자 A는 피해자 B가 접속하는 은행 사이트에 조작된 이미지 태그를 게시판에 남깁니다.

<img src="http://bank.example.com/withdraw?account=B&amount=100000&for=A" />

피해자 B 가 은행사이트에 접속하고 로그인하면 세션 정보가 남아있는 상태이고 이때 공격자 A가 게시판에 남겨놓은 글을 B 가 읽게 되면 해당 링크가 요청되면서 공격이 실행됩니다. 원래는 이미지를 불러오기 위해 지정된 이미지 링크롤 GET 메쏘드로 요청하게 되는데, 피해자 B가 인증되어 있는 상태인점을 이용하여 이렇게 우회공격을 할 수 있게 된 것입니다. 특히 대부분의 게시판들이 자바스크립트는 막아놓지만, 이미지 포스팅은 막지 않는 것도 공격에 유리한 상황을 만들어줍니다. 

최근에 발생했던 옥션의 1800만명 개인 정보 유출 사고는 CSRF 공격을 당한 것으로 밝혀졌다고 합니다. 중국 해커는 직접 서버를 공격하는 대신, 옥션 운영진을 대상으로 악성 코드를 첨부한 메일을 대량으로 유포했습니다. 운영자가 메일을 확인한 순간 ID를 얻을 수 있었고, 해커는 이 ID를 이용하여 옥션 서버에 로그인할 수 있었다고 합니다. (용어사전 CSRF의 내용을 일부 인용했습니다.)

이러한 취약점을 막는 가장 기본적인 방법은 서버의 상태를 변경하는 요청에 대해 GET 을 쓰지 않는 것입니다. 하지만 만일의 경우 공격자가 스크립트를 이용하여 POST로 보낼 수 도 있으므로 POST 메쏘드인 경우에도 대비를 해야합니다. 따라서 가장 일반적인 해결 방법은,
 1. 서버의 상태를 변경하는 요청은 GET 을 쓰지 않고,
 2. POST 의 경우에도 hidden 필드에 임의의 키값을 전달하고 그 키값이 맞는가를 매번 확인하는 것입니다.

하지만, 실제 보통의 웹 어플리케이션은 2번의 방비가 되어있지 않습니다. 이는 불특정 사용자가 서버의 상태를 임의로 변경할 수 있는 약점을 가지고 있게 합니다. 

장고(Django)에서는 1.2 버전부터 이러한 CSRF 취약점을 막는 기능을 기본으로 제공합니다. 모든 POST 방식의 폼 전송에는 hidden 필드로 세션에 따른 임의 키값을 전송하며, 해당 키 값이 유효한지를 매번 확인합니다.

이를 위해서는
 1. 설정파일(settings.py)에 미들웨어에 django.middleware.csrf.CsrfViewMiddleware를 추가하고,
 2. POST 가 사용된 폼 템플릿에 {% csrf_token %} 을 직접 삽입해야 합니다. 

<form action="" method="post">{% csrf_token %}

만일 미들웨어를 쓸 수 없는 경우라면, django.views.decorators.csrf 의 csrf_protect 장식자(decorator)를 쓸 수 도 있습니다.

from django.views.decorators.csrf import csrf_protect
from django.template import RequestContext

@csrf_protect
def my_view(request):
    c = {}
    # ...
    return render_to_response("a_template.html", c,
                               context_instance=RequestContext(request))

특정 뷰에 대해 csrf를 적용하고 싶지 않다면 csrf_exampt 장식자를 사용합니다.

from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def my_view(request):
    return HttpResponse('Hello world')

장고 뿐 아니라 최신의 웹 프레임워크 (Ruby on rails, Spring 등)은 모두 CSRF를 위한 별도의 방어 방법들을 제공합니다. 하지만 장고는 별도의 설정없이도 CSRF 대응이 가능하도록 구현되어 웹 초보개발자도 취약점이 존재하는 사이트를 만들 수 있는 여지를 사전에 차단한다는 점이 특징이라고 할 수 있습니다. 

인실리코젠 KM팀에서 구현하는 대부분의 웹 어플리케이션은 최신 버전의 장고를 사용하고 있으며, 중요한 보안위험요소들을 주기적으로 검토하고 있습니다.

펌 : http://www.insilicogen.com/blog/55

http://www.lgnsys.com/webzine/10/02/business/column_trend.jsp?bid=2001&aid=10000185&pageNum=1

netapp 씬 프로비저닝 기본원리 

대량의 스토리지를 할당하고 스토리지가 오랫동안 사용되지 않은 상태로 방치되는 여러 가지 상황이 있을 수 있습니다. 예를 들어 한 디자인 대학에서는 학생과 교직원용으로 27.5TB의 스토리지를 할당해야 한다고 예측했지만 대부분의 학생과 교직원은 스토리지를 조금만 사용하거나 전혀 사용하지 않았습니다.

하지만 이 학교는 NetApp 스토리지의 씬 프로비저닝을 사용하여 단 3.5TB의 물리적 스토리지(활용률 80%)를 통해 이러한 할당을 충족할 수 있었습니다(8:1 이상의 초과 할당률). 씬 프로비저닝을 사용하여 추가 스토리지 구입에 필요한 9만 달러 이상의 추가 비용이 절감된 것입니다.

NetApp 씬 프로비저닝은 물리적 스토리지 풀에 실제 존재하는 것보다 더 많은 논리적 스토리지를 호스트 또는 사용자에게 제공할 수 있도록 설계되었습니다. 공간을 미리 할당하는 대신 데이터가 기록될 때 각 볼륨 또는 LUN에 동적으로 스토리지 공간이 할당됩니다. 대부분의 구성에서는 볼륨 또는 LUN의 데이터가 삭제되고 Snapshot 복사본에서 이를 사용하지 않는 경우에도 공통 스토리지 풀에 여유 공간이 다시 생기게 됩니다.

스토리지 프로비저닝에 대한 이러한 접근 방식에는 다음과 같은 여러 가지 이점이 있습니다.

• 위의 예에서 제안한 것처럼 할당되었지만 사용되지 않는 많은 양의 스토리지를 절약할 수 있습니다.
• 높은 활용률로 인해 필요로 하는 스토리지 용량이 줄어들게 되므로 직접 자본 비용(capex)이 절감됩니다.
• 데이터 센터에서 스토리지가 차지하는 공간이 줄어들고 필요한 전력 및 냉각 수요가 감소되므로 운영 비용(opex)이 절감됩니다.
• 스토리지 가격은 지속적으로 하락하므로 추가 용량이 필요한 경우 해당 용량을 미리 구입하는 경우에 비해 더 저렴하게 구입할 수 있습니다.
• 단일 여유 스토리지 풀을 관리할 수 있기 때문에 용량 계획이 단순합니다. 여러 애플리케이션 또는 사용자가 동일한 여유 공간 풀에서 스토리지를 할당할 수 있으므로 일부 볼륨에서는 용량이 제한되고 다른 볼륨에서는 용량이 남는 상황이 발생하지 않습니다.
• 스토리지 환경이 더욱 민첩해지며 변화에 더 쉽게 대응할 수 있게 됩니다.

그림 1) 기존 프로비저닝과 NetApp 씬 프로비저닝 비교.

기본 원리 장에서는 NetApp 씬 프로비저닝 구현 방법, 가장 일반적인 사용 사례, SAN 및 NAS 환경 모두에서 씬 프로비저닝을 구현하는 사례 등에 대해 알아봅니다.

                                        ................

http://www.netapp.com/kr/communities/tech-ontap/tot-btb-thin-provisioning-1011-ko.aspx

NetApp에서 발표한 씬프로지비저닝에 관한 소개 자료입니다.

본문 내용 중 :

3. 씬 프로비저닝
3.1 정의
씬 프로비저닝이란 스토리지 시스템에서 실제로 사용할 수 있는 것보다 많은 스토리지 공간을 스토리지
시스템과 연결된 호스트 또는 서버에 제공하는 것입니다. NetApp 스토리지 시스템은 항상 이렇게 정교한 FC
및 iSCSI 프로비저닝 기능을 제공해 왔으며, Data ONTAP 7.0과 함께 출시된 FlexVol 기술은 이러한
유연성을 더욱 증가시켰습니다. 스토리지 시스템에 5,000GB의 가용 스토리지 용량이 있지만 스토리지
관리자가 15개의 호스트에 각각 500GB의 LUN을 매핑하는 것도 씬 프로비저닝의 한 가지 예입니다. 이
예에서 스토리지 관리자는 스토리지 시스템의 가용 공간이 5,000GB밖에 되지 않음에도 불구하고 호스트가
7,500GB의 스토리지 공간이 있는 것처럼 인식하게 만든 것입니다. 15개의 호스트가 제공된 500GB를 모두
한꺼번에 사용한다면 분명 문제가 발생할 것입니다. 스토리지 관리자는 시스템을 모니터링하여 필요에 따라
스토리지를 추가해야 합니다.
이러한 사례는 다른 산업 분야에서도 쉽게 찾아볼 수 있습니다. 예를 들어, 모든 사람이 동시에 수도꼭지를
튼다면 수자원관리공사와 같은 기관에서는 적절한 수압으로 물을 공급할 수 없을 것입니다. 이러한 기관은
특정 퍼센트의 사람만이 동시에 물을 사용한다는 사실을 전제하고 계획을 세웁니다. 마찬가지로, 은행도 모든
고객이 계좌에 있는 돈을 동시에 전부 인출할 수 있게 할 만큼 많은 현금을 보유하고 있지 않습니다. 은행은
특정 시기에 일정 퍼센트의 고객만이 돈을 인출할 것이라고 가정하고 계획을 세웁니다. 이 두 가지 사례는 씬
프로비저닝이 스토리지 분야를 비롯한 대규모 환경에 더 적절하다는 것을 보여줍니다. 스토리지 시스템의
규모가 크고 스토리지를 활용하는 사용자나 어플리케이션이 많을수록 씬 프로비저닝으로부터 얻을 수 있는
장점도 많아집니다.