블로그 이미지
redkite

카테고리

분류 전체보기 (291)
00.SI프로젝트 산출물 (0)
00.센터 운영 문서 (0)
01.DBMS ============.. (0)
01.오라클 (117)
01.MS-SQL (15)
01.MySQL (30)
01.PostgreSql (0)
01.DB튜닝 (28)
====================.. (0)
02.SERVER ==========.. (0)
02.서버-공통 (11)
02.서버-Linux (58)
02.서버-Unix (12)
02.서버-Windows (2)
====================.. (0)
03.APPLICATION =====.. (11)
====================.. (0)
04.ETC =============.. (0)
04.보안 (5)
====================.. (0)
05.개인자료 (1)
06.캠핑관련 (0)
07.OA관련 (1)
Total
Today
Yesterday

달력

« » 2024.4
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

공지사항

최근에 올라온 글

0004. 취약점 분석 운영

4. DB 취약점 분석 운영

가. 취약점 수집

기존 네트워크나 애플리케이션 취약점 분석 솔루션은 네트워크와 OS 보안에 있어 효과적 일 수 있지만 DB 취약점에 대한 정보를 제공하고 있지 않는다. 따라서, DB 취약점 분석에 서는 DB 취약점을 수집하여 DB 계층에 존재하는 서비스 거부 공격, Misconfigurations, 알려진 취약성 경고, 패스워드 공격 취약성 등과 같은 보안 사항을 다루어야만 한다. DB 취약점은 DBMS 벤더사나 컴퓨터 침해 사고 대응단(CERT, Computer Emergency Response Team)에 의해 공개되거나 혹은 악의적 의사를 가진 해커들에 의해 공유되고 있다. 이렇게 발표되는 취약점은 사실상 공개적으로 노출된 것이기 때문에 발표된 취약점 만을 대응하는 DB가 대응시점이 늦었다면 즉시 공격 위험에 노출 될 수 있다.
대표적인 DB 취약점인 버퍼 오버플로(Buffer Overflow) 공격은 그 종류가 매우 다양하 며 애플리케이션과 DB 레벨 내에 발생된다. 이러한 버퍼 오버플로의 가능성은 취약점으 로 분류하여 관리해야 한다.
취약점이란 실행되지 않도록 의도된 애플리케이션이 비인가 유저에 의해 실행되도록 하는 모든 시도 및 그 공격들로 정의된다. 애플리케이션 내 취약점들은 대개 프로그래밍 에러를 발생시키며, 특히 개발자들은 종종 gets(), printf() 등과 같은 함수를 사용함에 있어 그 보안상의 의미를 잘 모르고 있는데 많은 개발코드들이 애플리케이션 보안 취약점들이 잘 알려지기 이전에 만들어졌기 때문이다. 가장 위험한 취약점은 비인증 유저의 Aribitray 명령의 수행을 허용하는 것이다. 아무리 패스워드 및 인증 관리가 강화된다고 하더라도 이 러한 취약점을 이용하여 우회적으로 공격할 수 있다.

나. 취약점 제거

DB 취약점은 단순한 네트워크나 애플리케이션 취약점에 의해 서비스가 중지되는 수준이 아니라 개인정보보호 차원과 기업 기밀보호 차원에서 매우 중요한 관리 요소가 된다. 하지 만 여기서 고려해야 할 사항은 DB는 특성상 IT 인프라 내의 상시 운영시스템으로서 DB 취약점 제거를 위해 DB의 가동을 중지하기란 쉽지 않다는 것이다. 취약점의 성격과 위험 등급에 따라 단순한 Fix Script로서 취약점을 제거할 수 있는 가벼운 것도 있지만, DB의 패치(Patch)를 통해 취약점을 제거해야 하는 경우도 생기게 된다. 때때로, 이러한 패치작 업은 여러가지 오류로 인해 DB 재가동이 어렵게 되는 경우도 발생하게 되므로, DB 취약 점 제거를 위해 패치를 적용하는 경우에는 해당 벤더사 엔지니어의 조언이 필요하게 된다.

다. 취약점 개선 분석 비교

새로운 DB 취약점은 발표시기에 대한 예정이 없기 때문에 취약점 분석은 자주 하는 것이 바람직하다. 예를 들어, 지난 달에 DB 취약점 분석과 제거 작업을 수행하였지만 그사이 새로운 취약점 발표와 함께 공격 위험에 노출 될 수 있다. 사실상 DB 취약점 분석은 빠른 시간 안에 수행할 수 있지만 취약점 제거에 소요되는 노력과 시간은 만만치가 않다. 하지 만, 가능하다면 잦은 주기마다 취약점을 분석하여 새로운 취약점 발견과 기존 취약점의 제 거의 확인에 노력을 기울어야 한다.

 

Posted by redkite
, |

최근에 달린 댓글

최근에 받은 트랙백

글 보관함