공부하다가 DB의 데이터를 보호하기 위해 웹 서버와 분리하고, DB 서버의 IP를 사설로 하는 경우를 보았는데..
요즘도 그렇게 하나요?
데이터 보안을 위해 현재 기업은 어떠한 기술 및 연구를 하는지 알고 싶습니다.
암호학적인 것 말고.. 위에서 말한 분리적인? 배치적인 것이 궁금합니다.
아시는 분?^^
"하지만 간편하게 그냥 방화벽하나를 두고 DB와 WAS는 외부 통신을 막아버리는 방법도
사실은 방화벽이 뚫리면 어짜피 뚫리게 되는 DMZ구성-사설망 구조와 다를게 없다고 보여지고도 합니다.
실제로 그렇게 서비스 하는 곳도 많이 봤구요"
-> 이 말은 "사설망을 하나 방화벽을 하나 뚫기는 쉽다" 이 말로 이해해도 되는건가요?
"게다가 요새는 미드레인지 이상 서버들이 전부 파티셔닝이 가능해서
콘솔리데이션 구성으로 예전처럼 물리적인 뷰와 논리적인 뷰가 확 와닫지도 않아요.
거기에 가상화까지 더해지면 구성 자체가 매우 유연하게 되지요."
-> 혹시 가상화를 이용해서 구성되는 쉬운 예? 조금 더 쉽게 설명 해주실 수 있나요?ㅎ
(가상화를 이용해서 망?(시스템)을 분리하고 공유 메모리를 이용해 통신한다... 혹시 이런건가요?)
"Data를 보호하기 위한 인프라 구성의 최근 트랜드라는 질문에 제가 궁금해서
아는 바를 주저리 주저리 써봤습니다."
-> 이것에 관한 자료는 어떻게 찾아보면 좋을까요? (검색어라든지? 사이트?)
"그래서 결국은 어플리케이션 보안이 중요하고
나아가 혹시 어플이 뚫려도 최소한 유출만 되도록 하고
유출된 데이터도 쉽게 까(?)볼 수 없도록 열심히 연구하는게 아닌가 싶습니다.
운영 미숙/저품질 개발으로 어플리케이션에 구멍이 뚫리면
몇십억을 때려박아서 구성을 해도 아무 소용이 없으니까요."
-> 어플리케이션을 만들때 보안에 취약하지 않게 만들어야 한다는 말인가요?
OR 네트워크 보안에는 한계가 있고, 어플리케이션 보안 솔루션이 중요하다는 건가요?
너무 잘 써주셨지만, 내공이 부족한 관계로 귀찮게 해드리네요^^;;
감사합니다. 좋은 하루 되세요.
web이 뚫린 다는 것은, 그 밑단의 네트워크로 들어갈 수 있는 문이 열린다는 의미와 같습니다. 웹이 뚫리면 당연히 WAS의 구멍을 찾을 수도 있다는 얘기인데, 보통 이런 구조에서 WAS가 외부와 연결이 안되어 있다는 이유로 application의 logic에 허점이 많은 경우가 많습니다.
즉, 좋은 먹이감이라는 것이죠.
방어하는 입장에서의 1%의 확률은 낮을지 모르지만, 뚫는 입장에서의 1%확률은 해 볼만한 수치이니까요.
제 생각에는 어떤 웹 사이트를 만드느냐에 따라서 고려해야 할 보안 이슈들이 달라지기는 하겠지만
사이트에 파일을 올려서 악성코드를 전파하는 것은 fortigate등의 보안 장비를 통해서 어느정도 막을 수가 있다고 보고요
그 외에 cross-site scripting 등의 문제는 개발시 아키텍쳐를 잘 잡아서 구조적으로 해결하는 수밖에 없습니다.
DB연결 쪽의 정보가 노출되는 것은 어떻게든 연결을 해야 하기 때문에 어딘가에 그 정보가 존재할 수 밖에 없습니다.
시스템 성능 향상을 위해서는 WAS와 DB가 같은 머신에 있는 것이 가장 좋겠지만, 그런 물리적인 연결 보다는
전체적인 보안 정책을 어떻게 세우느냐가 가장 중요하다고 봅니다.
개발, 데이타의 관리, 유지보수, 시스템간의 연동 이 모든 것들의 하나의 통일된 정책에 의해서 이루어져야 하는 것이 맞다고 봅니다.
머 아시는 바 대로
DMZ 영역에 웹서버군을 두고
다시 방화벽 밑으로 사설망에 WAS나 DB를 두죠.
이 방법은 물리적으로나 논리적으로 많이 쓰이는 방법입니다.
그리고 Web Server도 아예 사설망에 두고 vpn을 써서 접속하는 방법이
제한된 유저에게 서비스할 때는 훨씬 더 좋다고 생각이 듭니다.
하지만 간편하게 그냥 방화벽하나를 두고 DB와 WAS는 외부 통신을 막아버리는 방법도
사실은 방화벽이 뚫리면 어짜피 뚫리게 되는 DMZ구성-사설망 구조와 다를게 없다고 보여지고도 합니다.
실제로 그렇게 서비스 하는 곳도 많이 봤구요.
게다가 요새는 미드레인지 이상 서버들이 전부 파티셔닝이 가능해서
콘솔리데이션 구성으로 예전처럼 물리적인 뷰와 논리적인 뷰가 확 와닫지도 않아요.
거기에 가상화까지 더해지면 구성 자체가 매우 유연하게 되지요.
Data를 보호하기 위한 인프라 구성의 최근 트랜드라는 질문에 제가 궁금해서
아는 바를 주저리 주저리 써봤습니다.
방화벽/IPS/IDS로 막고 SMS/NMS로 통합관리하면서
최대한 막고 빨리 감지하는 것 이상으로는
TCP/IP 기반 서비스에서는 막는 데 한계가 있다고 생각되어집니다.
그래서 결국은 어플리케이션 보안이 중요하고
나아가 혹시 어플이 뚫려도 최소한 유출만 되도록 하고
유출된 데이터도 쉽게 까(?)볼 수 없도록 열심히 연구하는게 아닌가 싶습니다.
운영 미숙/저품질 개발으로 어플리케이션에 구멍이 뚫리면
몇십억을 때려박아서 구성을 해도 아무 소용이 없으니까요.
감사합니다^^
와~ 자세한 답글 너무 감사합니다.^^
한 두가지 더 질문드려도 괜찮겠죠?ㅎ
"하지만 간편하게 그냥 방화벽하나를 두고 DB와 WAS는 외부 통신을 막아버리는 방법도
사실은 방화벽이 뚫리면 어짜피 뚫리게 되는 DMZ구성-사설망 구조와 다를게 없다고 보여지고도 합니다.
실제로 그렇게 서비스 하는 곳도 많이 봤구요"
-> 이 말은 "사설망을 하나 방화벽을 하나 뚫기는 쉽다" 이 말로 이해해도 되는건가요?
"게다가 요새는 미드레인지 이상 서버들이 전부 파티셔닝이 가능해서
콘솔리데이션 구성으로 예전처럼 물리적인 뷰와 논리적인 뷰가 확 와닫지도 않아요.
거기에 가상화까지 더해지면 구성 자체가 매우 유연하게 되지요."
-> 혹시 가상화를 이용해서 구성되는 쉬운 예? 조금 더 쉽게 설명 해주실 수 있나요?ㅎ
(가상화를 이용해서 망?(시스템)을 분리하고 공유 메모리를 이용해 통신한다... 혹시 이런건가요?)
"Data를 보호하기 위한 인프라 구성의 최근 트랜드라는 질문에 제가 궁금해서
아는 바를 주저리 주저리 써봤습니다."
-> 이것에 관한 자료는 어떻게 찾아보면 좋을까요? (검색어라든지? 사이트?)
"그래서 결국은 어플리케이션 보안이 중요하고
나아가 혹시 어플이 뚫려도 최소한 유출만 되도록 하고
유출된 데이터도 쉽게 까(?)볼 수 없도록 열심히 연구하는게 아닌가 싶습니다.
운영 미숙/저품질 개발으로 어플리케이션에 구멍이 뚫리면
몇십억을 때려박아서 구성을 해도 아무 소용이 없으니까요."
-> 어플리케이션을 만들때 보안에 취약하지 않게 만들어야 한다는 말인가요?
OR 네트워크 보안에는 한계가 있고, 어플리케이션 보안 솔루션이 중요하다는 건가요?
너무 잘 써주셨지만, 내공이 부족한 관계로 귀찮게 해드리네요^^;;
감사합니다. 좋은 하루 되세요.
서버 한두대 돌리는
서버 한두대 돌리는 작은 곳이 아니라면 거의 다들 분리할껄요.
제가 드나드는 공공기관들도 다 그렇게 돌리고 있습니다. (안그런곳 한군데 보기는 했지만)
php, asp 같은 경우는 그래도 웹서버에 해당 로직이 다 들어 있지만
jsp/servlet으로 WAS 연동해서 사용하는 경우는 WAS도 분리시켜버립니다.
이러면 웹서버에서는 자질구레한 html이나 이미지 파일만 올려 놓기 때문에 뚫어도 가져갈 것이 없습니다.
Written By the Black Knight of Destruction
Written By the Black Knight of Destruction
이해가 안돼는 부분이 있어서요.
APache를 앞단에 두고 html 이미지 처리하고
뒷단에 OC4J같은 (서블릿 java)등을 처리 하면 웹서버가 뚫리면 가저겨갈게 없다는데
이해가 안돼어서요..
로그인을 하던 게시판에 글을쓰던 결국 DAO나 DB pool에서 DB를 접근해야 될텐데
WEB-INF/Classes안에 .class로 되어 있겠죠.
Cross Site Scripting 이나 sql 인젝션 , 파일업로드등도 계속 우회기법 나오고
제로데이가 나오는데 가장흔한 위 취약점들도 Apache가 앞단에 따로 분리 되어있다고 한들
아무런 소용이 없어 보이는데요...
Apache가 따로 분리시켜 놓으면 좋은점은 로그 보기 좋죠 ,,성능도 더 좋아지고,,,어디가 부하가 많이 걸리는지 찾기도 쉽고,,,,
보안적인 면에서도 효율이 있다는건 동의하기 조금 어럽네요.
로그인, 게시판
로그인, 게시판 글쓰기 등등은 WEB 단에서 처리하는 것이 아니라 WAS단에서 처리합니다.
또한 파일업로드, SQL 인젝션 역시 WAS단에서 발생하는 문제입니다.
DB 접근은 WAS의 역할이니까요.
WEB 단에서는 전체 사이트에서 공통으로 사용하는 HTML 조각이나 이미지, CSS만을 가지고 있는데
이 경우에 WEB이 해킹으로 뚫리면 HTML 조각, 이미지, CSS만 가져갈 수 있기 때문에
보안적인 측면에서 봤을 때 중요 부분을 감출 수 있지요.
단 WEB 서버의 설정파일이 유출되어 WAS단의 접속정보가 유출이 되면 문제가 커지겠지요.
web이 뚫린 다는 것은,
web이 뚫린 다는 것은, 그 밑단의 네트워크로 들어갈 수 있는 문이 열린다는 의미와 같습니다. 웹이 뚫리면 당연히 WAS의 구멍을 찾을 수도 있다는 얘기인데, 보통 이런 구조에서 WAS가 외부와 연결이 안되어 있다는 이유로 application의 logic에 허점이 많은 경우가 많습니다.
즉, 좋은 먹이감이라는 것이죠.
방어하는 입장에서의 1%의 확률은 낮을지 모르지만, 뚫는 입장에서의 1%확률은 해 볼만한 수치이니까요.
인용: 이 경우에 WEB이
J2EE 환경의 사이트에 웹해킹이 발생할 경우 실제로 뚫리게 되는 대상은 WAS 서버이지 WEB 서버가 아닙니다.
----
LUX ET VERITAS | Just for Fun!
----
LUX ET VERITAS | Just for Fun!
그래서 보통 WAS나
보통 WAS나 내부에서 도는 DB, 기타 어플서버들은 외부 접근도 하지 못하도록 해놓습니다.
Written By the Black Knight of Destruction
Written By the Black Knight of Destruction
여러가지 경우가 있겠지만
제 생각에는 어떤 웹 사이트를 만드느냐에 따라서 고려해야 할 보안 이슈들이 달라지기는 하겠지만
사이트에 파일을 올려서 악성코드를 전파하는 것은 fortigate등의 보안 장비를 통해서 어느정도 막을 수가 있다고 보고요
그 외에 cross-site scripting 등의 문제는 개발시 아키텍쳐를 잘 잡아서 구조적으로 해결하는 수밖에 없습니다.
DB연결 쪽의 정보가 노출되는 것은 어떻게든 연결을 해야 하기 때문에 어딘가에 그 정보가 존재할 수 밖에 없습니다.
시스템 성능 향상을 위해서는 WAS와 DB가 같은 머신에 있는 것이 가장 좋겠지만, 그런 물리적인 연결 보다는
전체적인 보안 정책을 어떻게 세우느냐가 가장 중요하다고 봅니다.
개발, 데이타의 관리, 유지보수, 시스템간의 연동 이 모든 것들의 하나의 통일된 정책에 의해서 이루어져야 하는 것이 맞다고 봅니다.