kth 공통플랫폼팀 김정민
리뷰 글 : http://www.infoq.com/articles/nosql-data-security-virtual-panel
Posted by Srini Penchikala on Nov 15, 2011
요약(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프레임웍 등.
등이 존재하며 꼭 위의 프래임웍을 사용하지 않더라도 해당기능을 대치 할 수 있는 기능으로 사용하셔도 무방할 것으로 판단 됩니다.
There is No Security in NoSQL(NoSQL에 보안은 없다)
첫번째 문서로 뭔가 부족하다 싶어 인터넷을 뒤적이던 중 관련된 내용이 있어 첨부합니다. 보안 기능의 완성도가 떨어지는 NoSQL이 이미 사용되고 있는 부분에 대해 약간 부정적인 시각으로 바라보는 경향이 있는 것으로 보이나 읽어볼 가치는 있다고 생각합니다. 두번째 문서내용은 Cassandra 와 MongoDB의 보안에 대한 내용으로
두개의 데이터베이스에 대한 주요 문제점을 정리하면
- 데이터 파일에 대한 암호화의 부족
- 클라이언트와 서버, 그리고 서버간 미약한 인증
- 세밀한 권한인증 과 롤기반 접근제어에 대한 기능 지원 없는 매우 간단한 인증
- 그리고 SQL Injection과 DoS 에 대한 취약점
으로 결론 지었습니다. 아래 표를 기반으로 두가지 NoSQL의 보안관련 사항에 대한 현재 상태와 권장사항을 보실 수 있습니다.
카산드라의 권장 사항(0.8.x기준)
| Category | Status | Recommendations |
| Data at rest | 비암호화 . | OS 레벨의 메커니즘과 함깨 보호 되야함 |
| Authentication | 이용가능한 솔루션이 없음 | IAuthentication 커스텀 하여 적용 필요 |
| Authorization | 컬럼패밀리 단위의 적용
이용가능한 솔루션이 없다 |
IAuthority를 커스텀 하여 적용 필요 |
| Auditing | 쉽게 사용 불가 | 인증과 권한 솔루션의 부분으로 적용 |
| Intercluster network communication | 암호화 이용가능 | 사설 인증 기관 사용 |
| Client communication | 암호화 이용불가 | 알려지지 않은 호스트로부터 연결을 차단하기위해 패킷 필터 룰을 적용,
Thrift 0.6내의 SSL 전송을 사용하기위해 Thrift 서버측을 재 구현 Thrift서버측 안의 연결을 위한 타임아웃 추가와 연결가능한 클라이언트 수의 제한 |
| Injection Attacks | 카산드라 쿼리 랭귀지(CQL)을 통해 가능 | 자바드라이버를 사용한다면, 어플리케이션안에서 항상 입력검시 Statements 보다PreparedStatements 를 사용.
항상 어플리케이션의 입력을 검증 |
몽고디비의 권장사항(버전정보 없음)
잠깐 몽고 디비의 설계 원칙을 들여다보면 “몽고 디비 설계자들의 첫번째 관심사는 보안이 아니다 그결과로 디자인 자체에 몇개의 홀이 존제 한다.” 라고 표현 되 있습니다. 이것은 어찌보면 당연 할 수 있습니다. 사용자에 의해 선택되지 않았다면 보안적인 내용을 거론할 필요 조차 없을 것이고, 선택 될 수 있는 최우선 사항이 가용성과 확장성인 많큼, 보안은 순위에서 밀려 있는 상황이며, 이것은 어찌 보면 최초 설계에 있어 사치일수도 있습니다. 그러나 결국 보안이슈는 “어플리케이션이 통과 해야만 하는 마지막 관문 이지 않을까” 라는 생각이 드는 문구 였습니다.
| Category | Status | Recommendations |
| Data at rest | 비암호화. | OS 레벨의 메커니즘과 함께 보호 되야함 |
| Authentication for native connections | 샤드 되지 않은 상태만 이용가능 | 만약 가능하면 사용 |
| Authorization for native connections | 샤드 되지 않은 상태에서 읽기/읽기쓰기/어드민 적용 | 만약 가능하면 사용, 활성화된 인증 요구 하라 |
| Auditing | 이용불가 | |
| AAA (authentication, authorization, auditing) for RESTful connections | 사용자와 퍼미션이 외부로 연결 된 상태로 유지됨 | 만약 리버스 프록시로 조정가능하면 이용가능 |
| Database communication | 암호화 이용불가 | |
| Injection Attacks | 자바스크립트와 문자결함을 통해 가능 | 어플리케이션이 사리에 맞는 입력검증을 하는지 확인하라 |
이상으로 두개의 문서에대해 간략하게 NoSQL의 보안상 특징들을 알아봤습니다.. 주목할만한 내용 중 하나는 Ben-Gurion University Team (BGU)그룹이 2011년 11월에 “IEEE TrustCom-11” 에서 “Security Issues in NoSQL Databases” 라는 주제로 발표하였다고 합니다. 그들의 의견이 어떠한지 한번 읽어 보는 것도 가치가 있다고 생각 됩니다.( 원문 내용에 대한 번역본은 내용이 길어져 삭제 하였습니다. 필요하시면 메일로 연락주세요)
About the author
- More at
