다운타임을 없애면서 MySQL 데이터베이스의 보안 강화

오픈 소스 소프트웨어(OSS)는 최신 애플리케이션의 구축 방식과 기본 코드를 빠르게 변화시켰습니다. 개발자는 고품질의 강력한 오픈 소스 소프트웨어 프로젝트에 액세스하여 새로운 기능을 애플리케이션에 빠르게 통합할 수 있게 되었습니다. 그 결과, 현재 대부분의 최신 애플리케이션 코드의 80%에서 90%가 오픈 소스 컴포넌트로 구성되어 있는 것으로 추정됩니다. 마찬가지로 Jenkins, Kubernetes, Docker와 같이 데브옵스와 CI/CD의 성장을 가능하게 한 많은 도구는 그 자체로 오픈 소스 프로젝트입니다.

2019년에 발표된 전체 오픈소스 CVE(968개)는 전년 대비 두 배 이상 증가했습니다. 취약점은 2018년과 2019년 사이에 130% 증가했으며(421개에서 968개로), 두 번째로 많은 CVE가 발견된 2017년(435개)에 비해서는 127%나 높았습니다. 2020년 첫 3개월 동안 새로운 CVE의 발견도 역사적으로 높은 수준을 유지하고 있기 때문에 이러한 증가는 일시적인 현상으로 보이지는 않습니다. 이러한 양은 개발자, IT 및 보안 팀 모두에게 조직의 공격 표면 관리의 복잡성을 증가시킵니다. Jenkins 자동화 서버가 646개로 전체에서 가장 많은 CVE를 보유했으며, MySQL이 624개로 그 뒤를 이었습니다. 마찬가지로 이 프로젝트들은 무기화된 취약점(익스플로잇 코드가 존재하는 취약점)이 15개로 가장 많은 공동 2위를 차지했습니다. 이 문서에서는 이러한 소프트웨어 취약점의 원인을 조사하고 잠재적인 보안 사고로부터 MySQL 데이터베이스를 보호하는 방법을 보여줍니다.

콘텐츠:

1. MySQL에 대한 간략한 개요와 관계형 데이터베이스 시장에서의 중요성

2. MySQL의 취약점 

3. 패치되지 않은 데이터베이스 서버의 위험성

4. 취약한 데이터베이스 소프트웨어는 신속하게 패치해야 합니다.

5. 결론

MySQL에 대한 간략한 개요와 관계형 데이터베이스 시장에서의 중요성

시중에는 여러 데이터베이스가 있지만, 백엔드 내부 운영과 웹사이트 및 고객 포털과 같은 공개용 애플리케이션 모두에서 가장 널리 사용되는 데이터베이스 중 하나는 MySQL입니다. 오픈 소스 데이터베이스이긴 하지만, MySQL은 나중에 Oracle이 인수한 Sun Microsystems에 의해 인수되었습니다. 1990년대에 처음 소개되었지만, 당시 지배적이었던 Microsoft SQL Server 데이터베이스를 대체하는 인기 있는 옵션으로 빠르게 자리 잡았습니다. MySQL의 구문은 다른 SQL 언어(예: Oracle 및 Microsoft)와 유사하므로 보다 저렴한 데이터베이스가 필요한 개발자와 조직에 편리한 선택입니다.

현재 MySQL은 시장에서 가장 일반적으로 사용되는 관계형 데이터베이스 관리 시스템(DBMS) 중 하나입니다. A 2019 연구 에 따르면 MySQL이 시장의 38.9%를 차지했으며, 그 뒤를 이어 MongoDB가 24.6%, PostgreSQL이 17.4%를 차지했습니다. 오픈소스 데이터베이스 소프트웨어는 대부분의 웹사이트, 백엔드 시스템 및 기타 기업에서 운영하는 데이터 스토리지 서버를 지배하고 있습니다.

인프라를 실행하는 오픈 소스 소프트웨어는 업데이트, 버그 발견 및 기능에 기여하는 커뮤니티, 해커가 취약점을 찾아 악용하기 전에 발견할 수 있는 보안 연구원, 다른 개발자가 포크하고 사용자 정의할 수 있는 공유 리포지토리 등 많은 이점이 있습니다. 하지만 이러한 이점에는 단점도 있습니다. 공격자가 버그를 발견하면 이를 보고하지 않고 악용할 수 있습니다. 그 결과 익스플로잇이나 코드 취약점이 발견될 때까지 개발자가 알지 못하는 제로데이 취약점이 소프트웨어에 악용될 수 있습니다. 현재 악용되고 있는 취약점을 식별하는 데는 수년이 걸릴 수 있으므로 업데이트가 릴리스되는 즉시 MySQL 소프트웨어를 패치하는 것이 더욱 중요해집니다. 이러한 업데이트는 수개월 또는 수년 동안 존재할 수 있었던 취약점으로부터 시스템을 패치합니다. 익스플로잇이 민감한 정보를 저장하는 프로덕션 MySQL 데이터베이스에 영향을 미치는 경우, 조직은 가능한 한 빨리 시스템을 패치해야 합니다.

MySQL의 취약점 

MySQL이 대중에게 제공된 기간과 오픈 소스 코드베이스 사이에 데이터베이스 소프트웨어에는 수많은 CVE (공통 취약점 및 노출) - 총 1308개. 이러한 CVE 중 일부는 SQL 인젝션을 통해 웹 콘텐츠를 조작하고 영구적인 크로스 사이트 스크립팅(XSS)을 실행할 수 있는 PHP 애플리케이션 파일과 같은 애플리케이션 또는 소프트웨어와 관련이 있지만, 데이터베이스 엔진의 핵심을 겨냥한 취약점도 있습니다. 2020년에 발견된 일부 취약점은 권한 상승, 네트워크 액세스를 통한 MySQL 클라이언트 손상, 원격 코드 실행(RCE)을 허용합니다.

손상된 데이터베이스는 공격자가 데이터베이스에 액세스할 수 있도록 허용함으로써 여러 가지 다른 문제가 발생할 수 있으므로 매우 중요한 보안 이벤트입니다. 공격자는 익스플로잇에 따라 손상된 서버에서 데이터를 유출하거나, 서버에 대한 관리 권한을 부여하거나, 테이블에 자신의 데이터를 삽입할 수 있습니다. 지속적인 XSS 공격에서 데이터베이스 데이터를 인코딩하지 않는 모든 애플리케이션은 데이터 또는 쿠키 도난에 취약할 수 있습니다. 공격자가 서버에서 권한 상승을 수행할 수 있다면 데이터를 조작하거나, 공격자가 제어하는 서버로 데이터를 유출하거나, 기업 데이터베이스 전반에서 측면 이동을 수행할 수 있습니다. 원격 코드 실행은 공격자가 서버에서 키로거부터 랜섬웨어까지 다양한 멀웨어를 실행할 수 있기 때문에 특히 위험합니다.

패치되지 않은 데이터베이스 서버의 위험성

예를 들어 다음을 살펴보십시오. CVE-2020-2934. 이 취약점과 관련된 다른 CVE는 여러 가지가 있으며, 모두 MySQL 커넥터, 클라이언트 및 네트워크 세션에 영향을 미칩니다. 이 취약점을 성공적으로 익스플로잇하면 공격자가 데이터베이스 서버에서 CRUD(생성, 읽기, 업데이트 또는 삭제) 명령을 수행하거나 서비스 거부(DoS) 공격을 시작할 수 있습니다. CRUD 명령을 실행할 수 있는 공격자는 사용자의 데이터를 읽거나 변경할 수 있습니다.

데이터베이스의 데이터 유출은 고객 충성도, 신뢰, 매출, 생산성에 장기적인 영향을 미치는 중대한 사고로 간주됩니다. 대부분의 조직에는 내부 사고 대응 팀이 없기 때문에 시간당 수백 달러를 청구하는 외부 컨설턴트가 필요합니다. 경우에 따라 IT 관리자는 침해 사고를 억제하고 데이터베이스 서버에 대한 해커의 액세스를 차단하기 위해 중요한 시스템을 끄기로 선택합니다. 이러한 임시 조치는 공격자가 더 많은 데이터를 훔치는 것을 막을 수 있지만, 데이터베이스에 액세스해야 작동하는 애플리케이션도 중단됩니다.

공격자가 랜섬웨어를 사용하여 데이터를 암호화하거나 파일을 손상시키는 심각한 침해 사고는 백업과 데이터 복구 계획이 필요합니다. 대기업에서도 복구 계획이 실패하여 외부 컨설턴트의 지원이 필요할 수 있습니다. 데이터베이스가 다운되는 동안 조직은 다운타임으로 인한 매출 손실을 입게 되며, 대기업의 경우 시간당 수천 달러에 달할 수 있습니다.

데이터베이스 서버에서데이터 유출로 인한 비용은 침해 유형, 도난당한 데이터의 양, 사고 대응의 효율성에 따라 크게 달라집니다. 예를 들어, 캐나다의 대출 기관인 Desjardins Group 은 데이터 유출로 인해 회원 290만 명의 개인 정보가 유출된 후 5,300만 달러를 지출했습니다. 영국항공과 메리어트는 데이터 유출로 인해 GDPR (일반 데이터 보호 규정) 준수 규정을 위반한 후 각각 1억 달러를 지출했습니다.

취약한 데이터베이스 소프트웨어는 신속하게 패치해야 합니다.

MySQL용 MITRE 데이터베이스에 나열된 모든 CVE의 한 가지 공통점은 취약점이 있는 애플리케이션은 모두 패치를 적용해야 한다는 것입니다. CVE는 SQL 인젝션을 허용하는 타사 소프트웨어일 수도 있고, MySQL 데이터베이스 엔진 자체에서 다른 익스플로잇이나 취약점이 발견될 수도 있습니다. 타사 애플리케이션을 사용하지 않을 수도 있지만, MySQL 데이터베이스 취약점은 가능한 한 빨리 패치해야 합니다.

MySQL은 매우 중요한 인프라 구성 요소이므로 관리자와 데이터베이스 관리자(DBA)는 종종 패치를 추후 날짜로 예약할 수 있습니다. 또한 철저한 테스트를 수행하고 프로덕션 데이터베이스 서버의 다운타임을 피하기 위해 시스템 패치를 몇 주 동안 기다릴 수도 있습니다. 이렇게 하루하루가 지나갈 때마다 공격자는 패치되지 않은 MySQL 서버 소프트웨어를 익스플로잇할 수 있는 기회를 얻게 됩니다.

1300개가 넘는 CVE가 계속 발생하고 있는 상황에서 관리자와 DBA가 서버 패치를 따라잡는다는 것은 패배의 연속처럼 보일 수 있습니다. 프로덕션 서버의 다운타임은 생산성 및 매출 손실을 의미하며, 관리자가 바쁜 업무 시간 동안 서비스를 중단할 수 없기 때문에 일반적으로 일정을 잡기가 어렵습니다.

결론

서버를 최신 취약점으로부터 패치하고 보호하려면 재부팅하지 않고도 서버가 지속적으로 업데이트를 받을 수 있도록 라이브 패치를 사용하는 것이 정답입니다. 관리자가 재부팅하지 않고도 데이터베이스 서버를 패치할 수 있는 새로운 기능이 곧 출시될 예정입니다. 관리자는 KernelCare+를 사용하여 비용이 많이 드는 데이터 침해와 다운타임을 방지하고 중요한 데이터를 안전하게 보호할 수 있습니다.