悪意のあるユーザーは、組織の MySQL データベースを悪用する脆弱性を見つける可能性があります。 したがって、データベースのアクティビティを監視することは、あらゆるビジネスの中核的な実践となるはずです。 ハッカーは機密データを盗むことを目的とした攻撃を仕掛けます。その主な標的は組織の MySQL データベース サーバーです。 データベースは最も侵害される資産の XNUMX つであることが知られています。
なぜデータベースがこれほど頻繁に標的にされるのでしょうか? シンプル - データベースは、顧客記録やその他のビジネス機密データを保管する組織の中心です。 組織は、これらの重要な資産の保護に関しては最優先事項を置きます。
ハッカーや悪意のある内部関係者が機密データにアクセスすると、次のステップは迅速に価値を抽出し、損害を与えたり、ビジネス運営に影響を与えたりすることです。 財務的損失や風評被害とは別に、違反は規制違反、罰金、訴訟費用などを引き起こします。
以下のケーススタディを見てみましょう。データベース上での悪意のあるアクティビティにより、顧客が数百万ドルを失ったケースです。
ケーススタディ
会社名：キャピタルワン
リンク： https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
問題：
Capital One 銀行は、脆弱性攻撃により、150 億 XNUMX 万ドルという最も重大な損失を被りました。
結果：
Capital One銀行のソフトウェアエンジニアと元従業員が会社のサーバーに侵入し、顧客データを保持し、100億人以上の個人データを盗み出した。 アマゾン ウェブ サービスは顧客データベースをホストしており、ちなみにこのエンジニアも以前はアマゾンで雇用されていました。
裁判所とCapital Oneによると、ハッカーは140,000万件の社会保障番号と80,000万件の銀行口座番号を盗んだ。 さらに、数千万件のクレジット カード アプリケーションも侵害されました。 この盗難により、アメリカ人の社会保障番号に相当するカナダの社会保険番号 2005 万件が侵害されました。 データの盗難範囲は早くて2019年、最新ではXNUMX年にあった。
同銀行は、この侵害により、影響を受けた顧客の信用監視費用を含め、最大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`/ )) {
print “$fields[2] $fields[4]\n”;
}
mysql-zrm コマンドは、すべてのバックアップまたは特定のバックアップ イメージに対してカスタマイズされたプラグイン スクリプトを実行します。 次のコマンドは、9 年 2019 月 XNUMX 日のバックアップ イメージの PRODUCTS テーブルからの削除を検索します。
# mysql-zrm –action parse-binlogs \
–ソースディレクトリ /var/lib/mysql-zrm/pricebook/20061205142103 \
–parse-binlogs-plugin /usr/share/mysql-zrm/plugins/detect_deletion.pl
コマンドの出力には、有効な削除と悪意のあるデータベースの削除が含まれます。
同様に、顧客は独自のスクリプトを設定し、必要に応じてバックアップの前後に実行して検証することができます。これは、 MySQL 用の ZRM。
以下のスクリーンショットは、ZRM の「Backup|How」ページを参照しており、ここでプラグイン名、パス、および実行を構成できます。
Pre および Post バックアップ プラグイン パラメーターには、プラグインの名前とフル パスを含める必要があります。 プラグインの推奨場所は「/usr/share/mysql-isdatabase/plugins」ディレクトリです。
要約！
さまざまな脆弱性の脅威に対する意識が高まっているにもかかわらず、インシデントの数は近年増加しています。 これらの事件の被害者が負担したコストの結果、データ侵害の増加により運営コストが非常に大幅なレベルに増加しました。 これらのイベントの影響を軽減するには、組織は適切な手順を採用し、データ侵害や効率的な監視および検出ツールの欠如によって発生する総コストを最小限に抑える必要があります。
もチェックしてください ディザスタリカバリ計画に含めるポイント
