Posted by Srini Penchikala on Nov 15, 2011
http://www.infoq.com/articles/nosql-data-security-virtual-panel
요약(NoSQL 데이터베이스 접속 시 보안 고려사항)
기존의 RDBMS에 비해 NoSQL은 비교적 신기술에 해당하며, 보안 취약점 역시 RDBMS에 비해 더 많은 검증이 필요한 것이 사실입니다. 아래 언급된 내용 중 NoSQL이 향후3년간 집중과 관심을 받은 만큼 다양한 보안 이슈가 등장할 것으로 예상하고 있습니다. 오픈 소스 형태로 배포된 경우가 많아 취약점 역시 쉽게 노출될 것으로 보이며, 반면 문제점 역시 빠르게 해결 될 것이라 예상됩니다.
전반적인 대화 내용 중, 중요한 내용을 살펴보면, NoSQL 데이터베이스는 보안측면에서 기존 RDBMS와 별 차이는 없지만, 클러스터링 측면에서는 차이가 있는 것으로 판단되며, 각각의 DBMS별로 보안정책도 다르게 적용해야 한다는 사실을 알 수 있습니다. 보안에 대한 표준은 없으나 대부분 어플리케이션(미들웨어)에서 보안관련 내용을 처리 하는게, 보안관련 사항을 적용 하는 일반 적인 방법 이라 할 수 있겠습니다. 보안에 관련된 사항을 살펴보면
공통적으로(RDBMS,NoSQL) 주의해야 할 사항은
1. 부족하거나 잘못된 입력 검증
- 사용자가 입력한 내용 여과 없이 데이터베이스에게 전달 할 경우 SQL injection 같은 위 험에 노출 될 가능성이 있습니다. 입력된 내용을 어플리케이션 단에서 적절한 검증 또는 권장되는 함수를 통해 데이터베이스로 전달하는 게 중요하다고 판단 됩니다.
2. 어플리케이션 레벨 권한 핸들링 에러
3. 인증 취약, 보안되지 안은 통신
- 기본적으로 NoSQL의 설치 시 별다른 권한 인증 없이 동작 가능 하도록 디자인된 케이스들을 볼 수 있습니다. 이는 개발 시 편리성을 제공 하기도 하지만, 도메인 또는 자체적으로 별도 어플리케이션을 통하지 않고 접근이 가능한 케이스 일 경우 서비스 오픈 전 반드시 인증부분을 보완하여 적용하는 것은 필수라고 판단 됩니다.
4. 암호화되지 않은 데이터에 대한 불법 접근
- 데이터 베이스 자체가 암호화하여 저장하는 기능을 가지고 있지 않다면 중요한 내용들은 암호화를 통해 저장하는 게 올바른 선택이라고 생각 됩니다. 최근 주민등록 번호와 같은 개인정보들을 암호화 하여 저장되도록 방침이 정해진 것 역시 이러한 불법 접근에 대해 사전에 대비 하기 위한 것 이라 볼 수 있습니다. 접근 방법이 다양하여, 만약 어떠한 경우에라도 데이터가 노출이 될 경우, 암호화 된 데이터는 쉽게 접근이 불가능 할 것이며, 이는 최후의 보안정책 이라고도 할 수 있습니다.
이러한 공통적인 요소 외에도 NoSQL 제품들의 보안 취약성들이 존재합니다.
NoSQL측면에서 특별히 강조되는 부분을 살펴보면
1. 데이터베이스 종류에 따라 서로 다른 보안이 필요
- 아래 내용을 에서 Cassandra, MongoDB, CouchDB 는 서로 다른 인증방식을 취하고 있으며 심지어 같은 제품이라 하더라도 버전별 다른 기능을 제공 합니다. 이러한 점에서 각DB별 제공하는 보안기능을 미리 확인한 후 도입여부를 결정하는 것이 적절하다고 판단 됩니다.
2. 대부분의 NoSQL은 injection공격에 노출될 가능성이 있음
- 일반적으로 NoSQL은 injection공격에 취약하지 않다는 견해가 있는데, 이는 잘못된 견해이며, 어플리케이션 구현단에서 적절히 대처를 해야 합니다. NoSQL injection을 회피하기 위한 방법 중 하나로 권장함수 사용을 권하고 있습니다.
3. NoSQL 향후 3년이내 다양한 이슈 발견예상
- RDBMS는 오랜기간에 걸처 안정화 됬으나 지금까지도 보완강화를 위해 꾸준히 업데이트 중이며 반면, NoSQL경우 태생자체가 오래 되지 않아 수많은 검증이 필요하다고 판단 됩니다. 이부분은 꾸준히 업데이트를 통해 문제점을 보완해나가야 하며 MongoDB의 상용 버전과 같은 지속적으로 업데이트 가능한 제품을 선택하는 것도 최초 선택 시 중요한 사항이라고 생각 됩니다.
4. 클러스터 보안점 취약
- 샤딩, 리플리케이션, 클러스터링등 NoSQL자체가 대량의 데이터를 처리하기 위해 디자인된 많큼, 표면적으로 기존 RDBMS와 비교해볼 때 많은 부분이 노출 되 있다고 볼 수 있습니다. 또한 클러스러링 환경 자체가 속도나 퍼포먼스에 치중한 많큼 상대적으로 보안관련 기능이 취약 할 수 있으며, 이러한 특징을 잘 이해 할 필요가 있습니다.
이러한 보안 이슈를 해결하기 위해 일반적으로 권장 되는(표준화된) 방법은 없으며, 주로 미들웨어에 접근에 관리기능을 포함하여 개발이 진행되는 경우가 많습니다. 이럴 때 사용 할 수 있는
대표적인 미들웨어 는(자바 환경 일 경우)
1. JSSA(Java Authentication and Authorization Service)프레임웍
2. 스프링보안 프레임웍,
3. 아파치 Shiro 프레임웍,
4. J2EE프레임웍 등.
등이 존재하며 꼭 위의 프래임웍을 사용하지 않더라도 해당기능을 대치 할 수 있는 기능으로 사용하셔도 무방할 것으로 판단 됩니다.
아래 원문과 번역 내용을 첨부합니다. (번역 미숙으로 원문도 같이 첨부합니다.)
원문
Security Considerations in Accessing NoSQL Databases
NoSQL databases 는 기존의 RDBMS에 비해 semi-structured 또는 unstructured 데이터 저장에 대한 옵션형태의 지원을 제공한다. 비록 NoSQL database기반 개발은 최근 점점 더 많은 주목을 받고 있기는 하나, NoSQL 데이터에 대한 저장이나 접근에 대한 보안은 충분히 강조되고 있지 않다. 이 가상 패널의 토의 기사는 NoSQL 데이터 베이스 사용시 보안에 대한 고려사항 및 최적의 예제에 대해 초점을 맞췄다.
Panelists:
• Ben-Gurion University Team (BGU): The BGU team includes:
o Lior Okman
o Nurit Gal-Oz
o Ehud Gudes
o Yaron Gonen
They have recently published a research paper “Security Issues in NoSQL Databases” in proceedings of the IEEE TrustCom-11. Nov 2011, Changsha, China.
그들은 최근 IEEE TrustCom-11 에서 “Security Issues in NoSQL Databases” 라는 주제로 발표하였다.
• John Heasman: John is General Manager at NGS Secure. His areas of expertise include network and application penetration testing, vulnerability research, black-box testing and source code review.( NGS Secure 의 General Manager .네트워크 어플리케이션 테스트 전문가)
• Emil Eifrem: Emil is the founder of the Neo4j graph database project and CEO of Neo Technology.( Neo4j graph database project 최초 설립자이자 Neo Technology의 CEO)
Questions:
1. NoSQL 데이터베이스 사용시 어플리케이션 개발자가 사전에 알아야 할 필요가 있는 모든 보안상 취악점 은 무었인가?
2. NoSQL 구현 종류에 따라(문서기반,그래프기반 등)어떤 보안상 취약점이 존재 하는가? (Connection Pollution, JSON Injection, Key Brute Force etc.).
3. 인증, 접근, 컨트롤, 암호화 각각 용어들에 해당하는 NoSQL측면의 현재 보안 상태는 무었인가?
4. NoSQL 데이터 베이스 안에 저장된 데이터를 접근하는 어플리케이션에 대해, 보안을 구축 하기위해 어떤 툴과 기술이 아키텍트와 디벨로퍼를 위해 이용 가능한가?
5. 보안적인 측면에서, 기존 RDBMS 와 비교하여 장점과 단점은 무엇인가?
6. NoSQL 데이터 베이스의 보안성 검증을 위한 노력은 일반적인 자동 정적 동적 코드 분석, 침투 테스트, 수동 보안 코드 리뷰를 포함한 기존의 DB, 애플리케이션 개발과 어떻게 다른가?
7.NoSQL 기반의 어플리케이션 설계와 개발 시 보안의 모범사례와 처리하기 까다로운(gotchas) 사례들은 무엇인가?
8.NoSQL 의 보안성 측면에서 신경향은 무엇인가?
InfoQ: NoSQL 데이터베이스 사용시 어플리케이션 개발자가 알아야 할 필요가 있는 모든 보안상 취약점 은 무엇인가?
BGU: 어플리케이션 개발자들이 NoSQL 데이터를 사용하여 저장할 때 사전에 알아둘 필요가 있는 보안성 취약점은 관계형데이터 베이스를 사용할 때와 동일하다: 부족하거나 잘못된 입력 검증, 어플리케이션 래벨 권한 핸들링 에러, 인증 취약, 보안되지 안은 통신, 비 암호화된 데이터에 대한 불법 접근, 등. 최근 대부분 웹 앞단의 소프웨어는 미들웨어를 사용하고, 어플리케이션 레밸 뒤에서 타입에 관계없이 효과적으로 데이터베이스를 숨긴다. 접근 권한은 데이터베이스 레벨에서는 거의 다루지 않는다. 일부 케이스 에서는, 보통 RDBMS는 커낵션 풀링을 사용하기 때문에, 하나의 커낵션에 의해 사용된 특정유저를 구분 할 수 없다. 일부 관계형 데이터 베이스의 ACID기능역시 concurrency를 높이기 위해 또는, 미들웨상의 수평확장을 위해 무시된다. 이런 의미에서, RDBMS와 NoSQL의 차이는 거의 구분할 수 없다.
위의 일반적인 진술에도 불구하고, 세가지 주요 보안 취약점을 정의하면 (NoSQL 데이터 저장 구조를 사용하는 어플리케이션 개발자들이 가리킬만한 ): 웹 어플리케이션과 데이터베이스간 안전하지 않은 연결, DBA와 같은 특별한 권한을 있는 유저들을 위한 부족한 지원, 불충분한 인증 으로 구분할 수 있다.
추가적으로, 취약점이 존재 하는데, NoSQL을 사용하여 데이터를 저장할 때 통합자나 설계자들이 알아야 할 필요가 있다. NoSQL 데이터 저장은 내부적으로 수평 확장능력이 있으며(clustering, sharding, replication) 노드 위장 공격에 취약한 데이터저장부분에 대해 새로운 공격 방법을 제공하게 되었다. 대부분의 클러스터 솔루션은 그와 같은 계산된 행동에 대한 철저한 (보안)메커니즘을 제공하지 않는다.
John: 많은 NoSQL 데이터 베이스들은 복잡한 절차 없이 동작하도록 설계 되었다, 즉 인스톨 이후 거의 또는 전혀 튜닝 작업이 없으며. 인증은 거의 요구되지 않는다. 이는 실험환경하의 새로운 제품에 대한 테스팅을 위해서는 적합하나, 제품으로 출시하기 전에 명확한 대응이 요구 된다. 더욱이 인젝션 공격은 불가능 하다는 오해가 있다. 많은 NoSQL 데이터 베이스는 NoSQL 저장소 안으로 직렬된 객체를 직접 저장하는 인터페이스를 제공하며, 만약 이러한 인터페이스가 사용자에게 직접적으로 노출이 될 경우 악용 될 소지가 있다.
Emil: 특효법은 존제하지 않으나, 데이터는 저장되고, 보호될 필요가 있게 될 것이다 ,일반적으로 데이터의 형상에 따라 취약점의 차이는 거의 없다.(데이터 형태에 가 보안과는 무관하다는 의미)
그러나, 데이터와 함께 동작 시, 그래프 스토어들은 이점을 가지며, 비즈니스 정보를 나타내기 위해 맵리듀스 또는 유사한 프레임웍을 수반하는 어떠한 것도 필요하지 안다. 추가적인 처리를 없이 데이터 베이스 자체가 많은 정보를 포함하고 있다. 그것이 의미하는 바는, 동등한 내용을 처리하기위한 데이타 이동부분이 훨씬 적으며, 따라서 하둡과 비교 할 때 공격대상 표면이 적게 노출 된다는 것이다.(데이터 이동양이 적어 공격 표면이 훨씬적게 노출된다는 의미)
그 말인즉, 데이터를 변화시키는 쓰기 쿼리가 가능 하기 때문에, 유의사항은 요구사항들을 처리하는 그 쿼리들로부터 사용자단 조회에 처리에 대해 주의해야 할 것이다.(쓰기 쿼리에 대해 주의해서 처리하라는 뜻으로 해석됨)
InfoQ: NoSQL 구현 종류에 따라(문서기반, 그래프기반 등)어떤 보안상 취약점이 존재 하는가 ?(Connection Pollution, JSON Injection, Key Brute Force etc.).
BGU: 수십개의 서로 다른 NOSQL 데이터베이스가 존재하지만, 두가지 타입의(문서,컬럼기반) NOSQL 종류를 조사했다. 문서기반 데이터베이스는 MongoDB 와 CouchDB가 있으며 이들인 서로 다른 보안이 필요하다. 따라서 데이타베이스 종류에 따라 보안의 취약점 분류는 간단하지 않다는 걸 알았다.
일반적으로, 일부 소프트웨어는 (“hello world”와 같은 단순한 프로그램을 포함하여) 복잡성이 증가함에 따라, 어플리케이션의 공격 표면은 복잡성과 함께 증가 한다. 네트웍 지향적인 성격의 소프트웨어는 연결 오염이나 중간자(프록시) 공격에 취약하다. 사용자로부터 입력이 있는 일부 소프트 웨어는 이용자로부터의 공격에 취약하다, STMP 소프트웨로(STMP 해더) 부터 RDBMS(SQL injection)또는 NoSQL의 JSON/BSON/JavaScript injection(응용소프트웨어계층의 프로토콜 해더부터 DBMS에 이르기까지) 속임수(조작) 공격들에 취약하다. 이러한 의미에서 데이터 접근 인터페이스가 존재하는 대부분의 NoSQL은 인젝션 공격에 노출 되어있다고 볼 수 있다.
Emil: 우리는(Neo4j graph database) 그러한 어떠한 것들에게도 취약하지 않다: 우리는 JSON 저장소가 아니며, 보안관련 기능이 추가된 이후 취약하지 않다.
그럼에도 불구하고, 그래프 스토어에 접근했다면, 애플리케이션이나 유저에게 도움되지 않는 방향으로 컨텐츠 오류를 유발 할 수 있다. (일반적으로 어렵더라도)만약 파일시스템에 접근 가능 할 경우, 그래프의 부분을 수정하는 것을 포함하여, 직접적인 데이터베이스를 오염시키는 것은 가능하다
InfoQ: 인증, 접근, 컨트롤, 암호화 각각 용어들에 해당하는 NoSQL측면의 현재 보안 상태는 무었인가?
BGU: NoSQL 측면에서, 인증, 권한부여, 암호화를 위한 표준은 없다. 일반적으로, 이러한 것이 필요하다는 이해는 존재하지만, 아직 여기에 대한 최선의 방법이라고 인정할만한 것은 없다. 현장에서 현재 모범 사례는 미들웨어단에 보안이 위치해 포함되었으며, 클러스터 레벨에서는 보안이 무시된다.
특히, 우리의 조사는, Cassandra MongoDB, CouchDB를 위한 권한부여와 인증에 중점을 었는데,카산드라는 두 개의 도구를 복잡한 절차 없이 IAuthenticate 인터페이스와 함깨 노출시킨다. AllowAllAuthenticator능 기본적으로 인증이 불가능하나 반면 SimpleAuthenticator은 패스워드를 평문 저장상테에 따라 평문 또는 순수MD5의 사용이 가능하다. SimpleAuthenticator는 아직 상품으로 준비되었다고 생각되지는 않는다.
2.0버전에 앞서 최근 출시된 몽고에서의 인증은 파편화(shard) 되지 않은 경우만 지원 되며 실제 큰 의미는 없다.
CouchDB는 복잡한 절차 없이 세가지 인증 핸들러를 제공한다: 기본 HTTP인증, 쿠키 기반 그리고 OAuth 프로토콜 기반의 인증.
카산드라에서 권한부여는 컬럼 패밀리 단위로 처리된다. 현재 접근권한셋은 읽기와 쓰기를 포함한다. 카산드라는 두가지 방법의 IAuthority 인터페이스를 제공한다. 첫번째는 방법은 유저와 관계없이 항상 모든 접근을 허락하는 방법 이고, 그리고 두번째는 일반 자바 프로퍼티 파일을 유저이름과 접근권한 메칭을 처리하기 위해 사용한다
몽고디비는 두가지 타입의 유저를 지원한다: 데이터베이스 알갱이단 레벨이세 읽기만 또는 읽기 쓰기를 지원한다. CouchDB는 데이터베이스 알겡이 레벨에서 매우 제한적인 버전의 롤기반 접근 컨트롤을 제공한다.
세 개의 데이터 베이스 모두 데이터는 암호화 되지 않는다. MongoDB 암호화는 클러스터간 네트웍 커뮤니케이션은 가능하나, 클라이언트와는 불가능 하다. couchDB SSL 은 1.1.0버전에서 지원되며 클라이언트와 클러스터간 둘 다 지원 가능 하다.
Emil: 원래 가능하지는 않지만, 이 서비스들은 Neo4j와 쉽게 통합이 가능하다. 액세스 컨트롤은 특히 어떤 애플리케이션에나 자연스러운 부가 기능이며, 또한 권한정보와 함께 엔티티에 대한 주석을 직접 남기는 것이 쉽기 때문이다. 일반적인 경우, 모든 ACL을 그래프 내에서 직접 도메인에 붙이고 인증 체크를 간단하게 만든다.
InfoQ: NoSQL 데이터 베이스 안에 저장된 데이터를 접근하는 그들 어플리케이션에 대해, 보안을 구축 하기위해 어떤 툴과 기술이 아키텍트와 디벨로퍼를 위해 이용 가능한가?
BGU: 관계형 데이터베이스를 위한 가상 개인 데이터 베이스와 같이 보안이 내장되어 제공하는 툴을 찾지 못했습니다. 그러나, 다음과 같이 정의 했습니다. NoSQL에서 새로운 네임스페이스를 쉽게 만든 다는 것이, 그러한 보안에 제공되어 사용되어질 수 있다고. 예를 들어 ,하나의 네임스페이스에는 읽기만 ,또다른 하나의 네임스페이스는 읽기쓰기는 읽기 쓰기를 사용하는 것이다. (네임스페이스 별로 기능을 분리하여 사용하는 것이 보안에 도움이 될 것이라는 의견으로 보임)
대부분 미들웨어 소프트웨어는 인증, 권한 그리고 접근컨트롤을 위한 지원을 포함한다. 자바에서는, JSSA프레임웍, 스프링보안 프레임웍, 아파치 Shiro 프레임웍, J2EE프레임웍, 또는 기타 다른 라이브러리를 사용할 것이다, 추가적으로, NoSQL클러스터안에서, 전송으로 HTTP를 활용하는 ,보안은 역시 프록시서버와 로드벨런서들 통해서 검증할 수 있습니다. NoSQL 데이터 베이스는 보안문제를 풀기 위해 알맞게 디자인된 어플리케이션이 할 수 있는 것 만큼 보안문제에 대처 할 수 있는 기능은 없습니다. 현재 모범 사례는 미들웨어에 보안을 위치시키는 것입니다.
Emil: 임베디드된 데이터베이스로 디플로이 될 때, 보안은 단지 어플리케이션의 일부이며, 따라서, 사내 표준과 부합하여 일관성을 지키기 위해 무엇이든 사용 될 수 있다.
서버 개발자들은 사내 표준과 일관성을 지키기위해 수직적으로 보안 수칙을 시행 할 수 있다.
InfoQ: NoSQL은 보안측면에서 RDBMS와 비교해 봤을 때 장점과 단점은 무엇인가?
BGU: 대부분의 어플리케이션 개발자들이 NoSQL을 사용시 보안 핸들링은 미들웨어에 위치 시키며, NoSQL은 데이터 베이스 내부에 어떠한 보안기능도 필수로 제공하지 않는다. 보안기능이 제공되지 않는다는 점은 관계형 모델에 비해 단점이다. 데이터 베이스에 보안 능력은 일반적으로 필수는 아니다. 내가 보았던 대부분 어플리케이션은 ,(데이터 베이스 안의 보안 레이어는 유틸화 되지 았았으며, 왜냐하면 개발자들은 커낵션 풀을 사용하길 원하기때문데, 그리고 이미연결이 성립된 이후 인증을 다시 사용하길 원하며), 보안을 지원하지 않는다.(오라클은 프록시 인증을 통해 지원된다). NoSQL 솔루션은 일반적으로 클러스터 지향적이며, 그리고 이것은 가용성과 스피드면에서 장점이 존재한다, 그러나 보안에 있어서는 단점이 된다. 문제는 클러스터링 측면에서 NoSQL DB가 충분히 강력하게 성숙되지 못했다는 것이다.
그러나, DBMS 직접 접근하거나 어플리케이션을 통하지 않을 때, RDBMS는 내장된 보안 수단을 이용함으로써 NoSQL에 비해 커다란 장점을 가진다.
John:NoSQL 데이터베이스는 RDBMS에 비해 일반적으로 복잡하지 않다. 복잡하지 않다는 것은 보안에 있어 장점이다. 대부분 RDBMS는 많은 수의 특징들과 더불어 공격자 권한을 상승시키거나 서버를 좀더 위험에 노출시키기 위해 확장된 기능을 사용 할 수 있다.
1)확장된 저장 프로시져 – 이들은 호스트의 파일시스템과 내트웍과 상호작용기능을 제공한다. 스스로 많은 위험이 존재하는 것 뿐만 아니라 (SQL 서버의 xp_cmdshell은 어드민 유저를 시스템 명령어를 수행하기위해 허락한다) 버퍼 오버플로우와 같은 많은 수의 보안 문제를 가지고 있다.
2) 정의 되어 동작하는 저장 프로시져들 – Oracle 과 SQL Server와 같은 RDBMS들은 서로 다른 사용자 권한아래 동작하기위해 표준 저장 SQL을 지원한다. 이것은 리눅스안의 어리석은 프로그램와 유사한 경우이다.저장 프로시져안의 많은 권한 확대 취약점을 가지고 있으며 SQL injection 취약점들로 인해 저장 프로시져안의 SQL injection 으로인해 많은 권한 상승 취약점이 존재한다.
NoSQL 솔루션의 단점중 하나는 Oracle(SQL Server, MySQL , DB2)과 같은 RDBMS와 비교되는 성숙기 이다. RDBMS , 다양한 보안이슈가 논의되어 왔음에도 불구하고, 다양한 타입의. 공격 루트가 수년동 많이 알려져 왔다. 그에 비해 NoSQL은 시작 초기 단계이다. 그리고 전반적으로 새로운 종류의 보안 이슈가 발견될 가능성이 있다.
Emil: 인증이나 권한부여를 지원하는것, 그래프 데이터베이스는 RDBMS/KV stores 보다 명확히 더상위의 기능을 가지고 있다, 왜냐하면 보안 정책들은 데이터와 연관 될 수 있기 때문이다. 유져들은 다양한 그룹에 속할 수 있으며, 다양한 시스템 레벨에 대한 개개인의 접근 권한을 가지고 있다. 통합적인 권한 계산은 LDAP과 같은 트리를 사용하더라도 어렵다. 그러나 그래프 에서는 수월하다.
InfoQ: NoSQL 데이터 베이스의 보안성 검증을 위한 노력은 일반적으로 자동화된 정적과 동적 코드 분석, 침투 테스트, 수동 보안 코드 리뷰를 포함한 기존의 DB, 애플리케이션 개발과 어떻게 다른가?
BGU: 어플리케이션 측면의 차이는 없다. 어플리케이션에게 모든 열린 포트와 제공된 입력은 체크가 필요하다. 차이점은 클러스터 환경 안에 있다. 클러스터 스스로 대표적인 공격들 혹은 다른 클러스터 레벨의 데이터 절도 공격에 대해 취약하지 않다는 것을 확실히 하기 위해서는 더욱 많은 작업이 필요하다.
John: NoSQL 데이터베이스는 상당히 새로운 기술들이다. 새로운 기술들은 여전히 취약점이 존재한다. 만약 당신이 전통적인 RDBMS의 보안을 보았다면, 그들은 매우 얼룩진 보안역사를 가지고 있다. 거의 모든 주요 RDBMS는 한지점에서 다른 지점으로 원격 코드를 실행하는 권한에 대한 심각한 이슈를 가지고 있다. 그 보안 취약의 비율은 일반적으로 감소 되는 동안, 오라클과 같은 일부 는 아직까지 정기적으로 심각한 이슈를 풀기 위해 업데이트 발표 한다
NoSQL 데이터베이스는 자체 보안기능이 일부 존재 하지만, Oracle 과 같은 레밸은 아니며, SQL 서버와 MySQL은 Oracle 과 비슷한 수준이다. Memcached 개발자들은, 예를 들어,임의의 코드실행을 가능하게 했던, 몇몇 정수 오버플로우 이슈를 2009년에 풀었었다. 나는 NoSQL데이타 베이스 안에 넓은 범의의 이슈가 존재 할 것이라 예상하며, 나는 향후 3년 안에 NoSQL 데이터베이스가 인기를 얻은 많큼 그리고 보안연구가들로부터 주목을 받은 많큼 넓은 범위의(많은) 이슈가 발견 될 것이라 예상한다. 대다수의 NoSQL 데이터베이스는 오픈소스 이고 , 그래서 그 코드는 다운로드 되고 분석 될 것이며 이는 이러한 이슈를 해결하는데 확실한 도움이 될 것이다.
Emil: Neo4j에서 그러한 용이함은 아직 없다.
InfoQ: NoSQL 기반의 어플리케이션 설계와 개발시 보안의 모범사례와 처리하기 까다로운(gotchas) 사례들은 무었인가?
John: 직접 NoSQL 형태로 직렬화 하거나 사용자의 입력을 받아 드리는 형태는 어플리케이션을 부주의하게 만들게 되어 “NoSQL injection”에 영향을 받기 쉬운 가능성이 있다. 이것을 피하기 위해서는 생성이나 변경을 위해 지름길을 사용하거나 항상 입력검증을 해야 하는 것 대신 권장되는 함수들이 호출되도록 개발자들은 보장 해야 한다.
MongoDB와 같은 NoSQL 데이터베이스는 복잡한 절차 없이 작업하기 위해 디자인 되었다. 그래서 개발자들은 매우 빠른 작업이 가능합니다. MongoDB 의 기본은 인증이 설정되지 않은 상태 입니다. 반면 이것은 어플리케이션 개발의 초기 상태에 속도를 높이기 위해는 장점 이지만, 이러한 인증 및 권한 부여와 같은 보안 문제가 상용화 이전에 잘 해결되어야 합니다. NoSQL 데이터베이스에 대한 접근 도 재고 되어야 합니다. 멤케시와 같은 (인증요구가 없는) 원격 접속 키벨류 스토어를 대신할만한것을 찾는건은 쉽다.
Emil: 데이터 베이스와 마찬가지로, 어플리케이션은 데이터의 직접적인 접근을 유저와 분리 해야 할것이다. 쿼리 표현으로부터 어떠한 사용자 단의 조회 요청을 데이터베이스형태로 흡수하거나 식별하는 것 노출시키는 것을 피하라
InfoQ: NoSQL 의 보안성 측면에서 새로운 트랜드는 무었인가?
BGU: NoSQL데이타 저장에 있어 보안은 개발자들 사이의 전문 블로그로부터 배울만큼 하나의 주요 관심사 이다. 이 블로그를 읽어보면 개발자들이 실제로 NoSQL데이터베이스 사용을 피한다는 것을 알 수 있다. 따라서 우리는 더 많은 개발자들이 NoSQL 커뮤니티에 합류한 것을 볼 수 있으며, 밴더들은 끊임없이 인증과 권한 같은 기본적인 요구사항을 위한 보안의 필요성을 인지하고 고유의 솔루션을 더 많은 공급을 시도한다.
John: 마이크로소프트는 윈도우와 Azure cloud 에 대한 최근 하둡 적용 의도를 발표했다. iSec Partners로부터 보안 연구가들은 2010년 Black Hat USA 보안 컨퍼런스에 하둡 디자인을 이미 발표 했었으나 마이크로소프트의 이 발표는 추가적인 관심을 모을 것 이다.
Emil: 지난 과거 에는, 기업은 데이터 베이스 접근하기 위해 보안이 적용된 통제된 접근을 해야만 했으나, 오늘날 데이터 스토리지는 퍼시스턴스 레이어를 도메인 기반으로 접근 가능하다. 인증과 접근을 위한 책임은 어플리케이션 래밸에 쌓여 이동 되어지져, 다단계로 관리되는 보안 보다는 단순화된 보안으로 접근 하는게 용이하다. 이러한 방법은 웹 어플리케이션의 RDBMS 접근 시 역시 마찬가지이다. 데이터베이스에 접근하기 위해선 일반적으로 하나의 어플리케이션 계정이 사용된다. 모든 사용자와 퍼미션은 어플리케이션에 따라 다르게 관리된다.
My Blog 
