DataBase

[MariaDB] 보안 취약점 점검 #1 시작하며

빤따스뤽 2025. 2. 24. 22:12

서비스 중 개인정보를 DB에 저장하는 경우 여러가지 보안 조치가 필요 합니다.

그동안 실무에서 보안취약점 점검 수행 경험상 자주 등장했던 요구사항에 대한 내용 및 조치방법을 정리 해 보았습니다.

 

제가 제가 경험했던 5년간의 사례는 메이저 통신 3사, 약 15개 정도의 금융사와 개인정보 위/수탁관계로 거의 1한달에 한번씩 돌아가며 보안취약점 점검을 나오는 경험이 있었습니다.

 

애초에 설계를 신경써서 했음에도 불구하고 아예 대응이 비용, 시간 문제로 현실적으로 불가능한 경우도 있었고 서비스를 운영하고 있는 상황에서 적용하기가 매우 부담스러운 상황이 대부분 이었습니다.

 

애초에 개인정보처리시스템의 정의를 Back Office 어플리케이션으로 하지 않고 DBMS로 한정하였습니다.

그렇게 하기 위해서 Back Office에는 개인정보를 노출 하는 곳이 아예 없었습니다.

우리는 개인정보처리시스템이 없다는 단순한 논리로 막아질 줄 알았는데, 예상치 못하게 DBMS의 보안사항을 좀더 타이트하게 보는 당연한(?) 결과가 나와서 두고 두고 더욱 애를 먹었습니다.

BackOffcie 어플리케이션의 경우 시간과 공수를 들어스 그렇지 유연성이 있어서 권고사항을 검토해서 합당하면 그대로 고치면 되는데 DBMS는 직접 고치거나 플러그인을 개발 하기가 쉽지 않은 상항이다보니 더욱 그랬습니다.

 

MariaDB기준으로 개인정보처리시스템 보안취약점 검검에 자주 등장하는 내용을 살펴보고 이것을 어떻게 처리해야 하는지, 정리를 해보고자 합니다.

 

 

0. 준비

MariaDB 10.7.0 이상이 필요 합니다. 그 이전 버전에서는 몇가지 보안플러그인을 지원하지 않아서 기본 적인 것만 해야 합니다.

기존 운영 시스템이라면 어쩔 수 없지만, 새로 설치하는 것 이라면 10.7이상 버전을 설치하는게 좋습니다.

 

이 글에서는 Ubuntu 24.10, MariaDB 11.4.3 기반으로 테스트 하였습니다.

 

1. 보안을 고려한 물리적 구성  및 HA(고가용성) 구성

1.1 방화벽

서비스 네트워크 구성에는 반드시 방화벽이 필요 합니다.

방화벽이 없이 서버만을 배치하고 일반적인 배포판을 설치한다면 1달 이내에 IDC에서 연락이 올 것이며

우리의 서버는 DDOS 노드로 전락하여 수많은 트래픽을 발생 시킬 수 있습니다.

한번 침입을 받은 시스템은 높은 확률로 백도어가 설치되어 있을 가능성이 있기 때문에 원인을 찾아서 제거하는 것 보다

서비스를 중단하고 새로 설치하는 것이 더 안전하고 시간과 비용이 적게 든다고 생각합니다.

방화벽, 침임탐지시스템, 웹방화벽등 여러가지 보안 시스템을 앞단에 둘 수 있지만 비용이 많이 드는 것을 고려해도 최소한 방화벽은 꼭 있어햐 합니다.

방화벽은 기본적으로 inbound는 모두 차단후 필요한 포트와 IP만을 허용하는 방식으로 설정해야 합니다.

 

1.2 망분리

DB는 기본적으로 물리적인 네트워트에서 외부와 고립되어 있는 것이 좋습니다.

외부에서의 다이렉트로 DB에 접근은 불가하도록 물리적으로 구성합니다.

App/API 서버 기준으로 공인망(Public Network)와 내부망(Private Network)로 나누고 DB서버는 App/API 서버를 통해서만 접근 할 수 있도록 분리 해야 합니다.

DB서버에서 공인망으로 접근 역시 차단되어 있기에 DB서버가 내부망에 고립되어 있다는 점은 유지보수에 매우 불편한 점이 있습니다.

많은 경우에 내부망과 개발/운영 조직간에 사설망을 설치해서 쓰기도 하고, VPN을 구성해서 특정 위치에서만 접근 가능하도록 구성을 하기도 합니다.

과거에는 VPN을 사용하는 방식이 사설망을 다이렉트로 연결 하는 것보다 보안에 취약하다는 견해가 있었으나

요즘 AWS 같은 클라우드 서비스가 활성화 되면서 VPN 방식도 유연하게 봐주는 편인것 같습니다.

 

1.3 HA(고가용성) 구성

전통적인 HA 구성방식은 두대 이상의 DB서버를 구성하고 한쪽으로만 서비스(Active)를 하면서 변동되는 Data를 대기중인 서버(Standby)로 복제 해주는 방식입니다.

안정적이고 Active 서버에 장애가 발생했을때 빠른 시간안에 Standby로 대체헤서 서비스를 할 수 있습니다.

하지만 대부분 고사양 하드웨어로 구성되는 DB서버의 특성상 장애가 발생하기 전 까지 계속 대기만 하고 있어야 한다는 점은 퍼포먼스 관점에서 본다면 매우 아까운 비용입니다.

그래서 요즘은 Active(Read-Write) - Active(Read Only) 구성으로도 많이 구성하는 편 입니다.

서버 두대를 모두 놀리지 않고 쓸 수 있다는 장점이 있지만

어플리케이션에서 읽기/쓰기 요청과 읽기 요청을 분리해서 호출해야 하기 때문에 서비스 개발에 복잡도가 올라가는 경향이 있습니다.

현실적으로 DB서버 여러대가 동시에 같은 스토리지를 접근해서 Read/Write Access를 할 수 있는 RDBMS는 현재 기준 Oracle Enterprise Edition RCA에서만 가능합니다.

기업들이 비싸도 Oracle를 사용할 수 밖에 없는 큰 이유라고 생각합니다.

MariaDB가 오픈소스 기반이지만  MariaDB의 특성을 잘 이해하고 운영한다면 상용 RDBMS 못지 않은 성능과 안정성을 보여준다고 생각합니다.

고가용성 관련 내용은 원래 주제와 벗어나므로 안정적인 운영을 위해 2중화 구성이 필요하다는 관점만 이해 하고 넘어가는게 좋겠습니다.

 

2. 보안 취약점 점검

보안취약점 점검에 단골로 등장하는 항목입니다.

  • 개별 사용자를 분리하여 계정을 부여하고 사용자의 롤에 따라 권한을 다르게 부여하고 있는가?
  • 사용자 계정의 비밀번호는 안전한 알고리즘을 이용하고 있는가?
  • 사용자 계정의 비밀번호 만료 기간을 강제 하고 있는가?
  • 사용자 계정의 비밀번호의 복잡도를 일정 수준 이상으로 강제 하고 있는가?
  • 개인정보 시스템은 외부에서 접근 불가능한 공간에 안전하게 운영되고 있는가?
  • 개인정보 컬럼은 암호화되어 저장되고 있는가?
  • 개인정보를 조회(다운로드)등 하는 경우를 제한 하거나 모니터링 하고 있는가?
  • DATA 백업은 정기적으로 이뤄 지고 있는가?

이외에도 점검 항목이 많겠지만 비용을 들이지 않고 쉽게 적용 할 수 있는 부분을 중심으로 정리 해보겠습니다.

 

3. 결론

보안 이라는 것이 끝이 없고 하면 할 수록 비용이 들고, 불편해 지며 성능이 떨어질 수 밖에 없습니다.

다음에는 위에 취약점 점검 항목에 대해 확인 및 MariaDB 자체의 기능으로 실무에서 어떻게 적용하는지 실습을 해보도록 하겠씁니다.

 

끝.

 

저작자표시