악의적 인 사용자는 조직의 MySQL 데이터베이스를 악용하는 취약점을 찾을 수 있습니다. 따라서 데이터베이스 활동 모니터링은 모든 비즈니스의 핵심 관행이어야합니다. 해커는 기밀 데이터를 훔치도록 설계된 공격을 촉발하며, 그들의 주요 목표는 조직의 MySQL 데이터베이스 서버입니다. 데이터베이스는 가장 많이 손상된 자산 중 하나로 알려져 있습니다.
데이터베이스가 그토록 자주 대상이되는 이유는 무엇입니까? 단순성 — 데이터베이스는 고객 기록 및 기타 기밀 비즈니스 데이터를 저장하는 모든 조직의 핵심입니다. 조직은 이러한 중요한 자산을 보호 할 때 최우선 순위를 부여합니다.
해커와 악의적 인 내부자가 민감한 데이터에 액세스하면 다음 단계는 신속하게 가치를 추출하고 피해를 입히거나 비즈니스 운영에 영향을 미치는 것입니다. 재정적 손실 또는 평판 손상 외에도 위반은 규제 위반, 벌금 및 법적 수수료 등을 초래합니다.
고객이 데이터베이스의 악의적 인 활동으로 인해 수백만 달러를 잃은 사례 연구를 아래에서 살펴 보겠습니다.
사례 연구
회사 명 : Capital One
링크 : https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
문제 :
Capital One 은행은 취약성 공격으로 인해 150 억 XNUMX 천만 달러의 가장 큰 손실을 입었습니다.
결과:
소프트웨어 엔지니어와 Capital One 은행의 이전 직원이 회사 서버를 해킹하여 고객 데이터를 보유하고 100 억 명 이상의 개인 데이터를 유출했습니다. Amazon Web Services는 고객 데이터베이스를 호스팅하며 우연히도 엔지니어는 이전에 Amazon에 고용되었습니다.
법원과 Capital One에 따르면 해커는 140,000 개의 사회 보장 번호와 80,000 만 개의 은행 계좌 번호를 훔쳤습니다. 또한 수천만 건의 신용 카드 신청도 유출되었습니다. 도난은 미국인의 사회 보장 번호에 해당하는 백만 개의 캐나다 사회 보험 번호를 손상 시켰습니다. 데이터 도난 범위는 빠르면 2005 년이었고 가장 최근에는 2019 년이었습니다.
은행은 침해로 인해 영향을받는 고객에 대한 신용 모니터링 비용을 포함하여 최대 150 억 XNUMX 천만 달러의 비용이 발생할 것으로 예상했다는 진술을 제공했습니다. 방화벽에 취약점이 열려 있고 해커가 AWS에서 호스팅 된 데이터베이스에 쉽게 액세스 할 수 있기 때문에 침해가 가능했습니다.
AWS의 전직 직원이었던이 취약성은 데이터베이스를 해킹하고 고객 데이터를 조작하기 위해 잘 악용되었습니다. 취약점이 어떻게 사용되었는지에 대한 가능한 노하우.
우리가 알고 있듯이 데이터베이스는 모든 고객 및 트랜잭션 데이터를 저장하는 데 사용됩니다. 해커는 은행 데이터베이스에서 데이터를 추가 / 제거하거나 추출하여 DB를 조작했습니다.
이 데이터베이스를 모니터링 할 적절한 보안이 있다면 다음을 사용하여 수행 할 수 있습니다. 즈 만다 ZRM 제품, 이러한 위협이 감지되어 사전에 발생하지 않도록 차단할 수 있습니다. 은행은 취약점을 수정했으며 이제 이러한 사기를 제어하기위한보다 엄격한 방법을 갖추고 있습니다.
악성 감지 Zmanda를 사용한 MySQL 데이터베이스 활동
조직은 다 계층 데이터베이스 보안 방어 전략을 채택해야합니다. 모범 사례를 채택하면 다음으로 인한 데이터 노출 위험을 현명하게 줄일 수 있습니다. 다양한 공격 벡터. 예를 들어 Zmanda는 데이터베이스 백업에서 악성 활동을 감지 할 수 있습니다.
MySQL 용 ZRM 데이터베이스 백업의 일부로 MySQL 바이너리 로그를 저장합니다. 바이너리 로그는 모든 데이터베이스 활동에 대한 적절한 감사 추적을 제공합니다. ZRM for MySQL 바이너리는 특정 시점 복구에 대해 로그 구문 분석 기능을 사용하여 SQL 검사를 사용하여 악성 데이터베이스 활동을 감지합니다.
ZRM for MySQL 플러그인 인터페이스를 사용하면 DBA (데이터베이스 관리자)가 로그 파서 플러그인 스크립트를 작성하여 특정 / 모든 데이터베이스 활동을 추적하고 모니터링 할 수 있습니다. 예를 들어, 다음 코드는 데이터베이스의 PRODUCTS 테이블에서 데이터 삭제를 감지 할 수 있습니다. 이 스크립트는 PRODUCTS 테이블에서 삭제 된 라인 항목의 모든 인스턴스를 인쇄합니다.
@fields = 분할 (/ \ | /, $ ARGV [0]);
내 $ SQL_VERB =”DELETE”;
내 $ TABLE_NAME =”제품”;
if (($ fields [3] ==“쿼리”) && \
($ fields [4] = ~ / $ SQL_VERB * FROM. *`$ TABLE_NAME` /)) {
“$ fields [2] $ fields [4] \ n”인쇄;
}
mysql-zrm 명령은 모든 백업 또는 특정 백업 이미지에 대해 사용자 정의 된 플러그인 스크립트를 실행합니다. 다음 명령은 9 년 2019 월 XNUMX 일자 백업 이미지의 PRODUCTS 테이블에서 삭제를 찾습니다.
# mysql-zrm –액션 구문 분석-binlogs \
– 소스 디렉토리 / var / lib / mysql-zrm / pricebook / 20061205142103 \
-parse-binlogs-plugin /usr/share/mysql-zrm/plugins/Detect_deletion.pl
명령의 출력에는 유효한 삭제와 악성 데이터베이스 삭제가 포함됩니다.
마찬가지로 고객은 자신의 스크립트를 설정하고 필요에 따라 백업 전후에 실행하고 확인할 수 있습니다. MySQL 용 ZRM.
아래 스크린 샷은 ZRM의 Backup | How 페이지를 참조하여 플러그인 이름, 경로 및 실행을 구성 할 수 있습니다.
사전 및 사후 백업 플러그인 매개 변수에는 플러그인의 이름과 전체 경로가 포함되어야합니다. “/ usr / share / mysql-is database / plugins”디렉토리에있는 플러그인의 권장 위치입니다.
마무리!
다양한 취약성 위협에 대한 높은 수준의 의식에도 불구하고 최근 몇 년간 사고의 수가 증가했습니다. 이러한 사고의 희생자에게 발생하는 비용의 결과로 데이터 유출 증가로 인해 운영 비용이 매우 크게 증가했습니다. 이러한 이벤트의 영향을 줄이려면 조직은 데이터 유출로 인해 발생하는 총 비용을 최소화하고 효율적인 모니터링 및 탐지 도구가없는 적절한 절차를 채택해야합니다.
또한 확인하십시오 재해 복구 계획에 포함 할 사항
