[ビッグガイがやってくるエピソード9] データセキュリティとデータベースセキュリティの黄金律

[51CTO.com からのオリジナル記事] ライブショー「ビッグネームがやってくる」の今回のエピソードのゲストは、北科不動産のテクニカルディレクターであるホウ・シェンウェン氏です。彼の共有トピックは「データセキュリティのためのデータベースセキュリティの黄金律」です。彼は、Oracle データベースのセキュリティ強化を例に、混沌としたデータベースの管理を標準化する方法に関する 36 の黄金律について詳しく説明しました。

データベースセキュリティ計画のための36の戦略

データ業界での長年の経験に基づいて、「左と右」の理論を共有したいと思います。

データベースセキュリティの分野では、最善の戦略は逃げることであり、これは脱出メカニズムに相当します。データベースのセキュリティを確保するための有効なセキュリティメカニズムがない場合、重大な障害が発生すると、受動的に逃げることしかできません。右側は、遠くから計画を立てて戦いに勝つことであり、これは、データベースに問題が発生したときに無力にならないように、事前に多くの安全なアクションを実行することと同じです。左でも右でも、答えは明らかです。

次に、下の図に示すように、現在のデータの状態を分析してみましょう。

管理仕様を持つデータベースは、データベース名を除いて同じです。いわゆる同じとは、セキュリティ強化方法と保証仕様を指します。標準化のみがツール化につながり、ツール化のみが製品化につながり、製品化のみが真の無人状態でのインテリジェント強化に移行できます。逆に、適切に管理されていないデータベースでは、名前は同じでも構成やデプロイメントの問題が異なり、さまざまなセキュリティリスクと脆弱性が生じます。

では、混沌としたデータベースの管理を標準化し、戦略的な計画の状態を実現するにはどうすればよいでしょうか?下の図に示すように、36 個の黄金律を要約して皆さんと共有します。

実際の生産における環境安全強化の豊富な経験に基づいて、三十六計略は、異なる段階と異なる次元で、勝利のための戦略、敵と戦うための戦略、攻撃するための戦略、接近戦のための戦略、敗北のための戦略の5つの方向に分割されています。

勝利戦略

勝利のための戦略は何ですか?戦わずに敵を追い払う者が戦いに勝つ。実際の生産環境では、運用および保守プロセス中に障害が発生することは避けられません。コンポーネントを適切に準備し、標準化することで、障害を効果的に削減、回避、回避できます。この方向性には合計 8 つの戦略があり、以下で 1 つずつ詳しく説明します。

最初の戦略: 効果的なバックアップが何よりも重要

DBA またはデータセキュリティ防御者にとって、有効なバックアップがない場合、重大な障害に遭遇したときにできる唯一のことは逃げることですが、これは多くの関係者が望まない状況です。したがって、災害が発生したときにパニックに陥らずに冷静でいられるように、あらゆる事態に備えて効果的なバックアップを作成することが重要です。

いわゆる災害とは、データが誤って削除、変更、改ざんされることです。バックアップがあれば、回復できる可能性があります。適時性の問題はありますが、データ量が多くなるほど復旧コストが高くなり、復旧が即時に行われない可能性がありますが、完全な災害復旧計画が確立されていれば、復旧時間は適切に制御されます。

DBA やデータセキュリティ担当者を夢から覚ます唯一のものは、バックアップの欠如です。なぜなら、データ自体がビジネスであり、実稼働環境の最も重要な資産だからです。実稼働データベースは畏敬の念を持って扱う必要があります。

計画2: 緊急時対応計画を策定し、訓練を実施する

バックアップがあるにもかかわらず、リカバリプロセス中にバックアップメディアが使用できないことが判明した場合はどうすればよいでしょうか。したがって、緊急時対応計画を策定し、その計画が有効かつ実行可能であることを確認する必要があります。同時に、訓練の実施を主張する必要があります。訓練がなければ、計画は単なる口先だけのものになってしまいます。また、実際に障害が発生していない場合でも、回復プロセスで時間を無駄にしないように、四半期ごと、半年ごと、または 1 年ごとにメディアの有効性を検証してください。

3番目の戦略: 災害復旧またはオフサイトバックアップを確立する

実際の運用環境では、運用コンピュータルームは同じ場所にあることがよくあります。バックアップをローカルサーバーに配置したとしても、極端な状況ではどうすればよいでしょうか。たとえば、自然災害によりコンピュータルーム全体が破壊された場合、依然として効果的な保護を提供できません。銀行や通信レベルなど、データの損失が絶対に許されない特殊な状況では、多くの場合、データの保持を保証する必要があります。そのため、災害復旧サイトまたはオフサイトバックアップを確立する必要があります。

4番目の戦略: データのアーカイブと読み取りと書き込みの分離

どのような本番環境でも、時間が経ち業務が拡大するにつれて、データが増え続け、データベースの読み取りや書き込み、パフォーマンスがどんどん悪化します。一定のレベルまで蓄積されると、本番環境の正常な使用に影響するため、データのアーカイブは不可欠です。データアーカイブは、データをオフラインで保存してデータ損失を防ぐだけでなく、メインの本番データベースのパフォーマンスを最大化することもできます。読み取りと書き込みの分離は必須です。メインサイトを分割して別のサイトに解放し、データベースの読み取り操作を別のサイトで実行し、データベースの書き込み操作をメインサイトで実行できるようにする必要があります。

本番環境の主な運用データであり、アーカイブ可能なデータを分類するなど、データアーカイブの仕組みを確立することを忘れないでください。読み取りと書き込みの分離を実装する前に、アーキテクチャ上の優先順位の設計を行う必要があります。

第5の戦略: テスト環境と本番環境を分離する

DBA が犯す一般的なミスは、メインの機器を生成とテストの両方に使用することです。これは大きなリスクを生みます。誤って間違ったデータベースに接続すると、実稼働環境のデータセキュリティが直接脅かされます。ここでネットワークレベルの分離を実行することを強くお勧めします。また、実稼働環境ではテストを実行してはならないことに注意してください。

注意すべき点は2つあります。1つはデータベースをアプリケーションシステムの末端に置き、保護すること、もう1つはデータベースを外部アクセスリンク下に置かず、イントラネット環境で運用することです。

戦略6: 導入基準と包括的な監視システム

障害は避けられません。問題をできるだけ早く発見して解決するには、一連の展開標準と完全な監視システムが必要です。監視の目的は、早期警告を発し、障害を早期に検出することです。障害が使用できない、またはデータが失われているというビジネスフィードバックを待ってから受動的に対処する必要はありません。それでは手遅れになります。

戦略7: 標準を開発し、実装する

何年も実践すれば、多くの経験が得られます。これらの経験をまとめ、標準として定式化し、実装することが、失敗を減らすための基礎となります。包括的な仕様により、開発者とオペレーターの間でさらなる標準化が促進されます。

標準化が確立されれば、リファレンスやベースラインが確立され、将来的にはツールや製品開発が可能になります。また、データの棚卸し後は、インテリジェントな運用・保守やセキュリティ強化の計画も可能になります。

戦略8: 自動化とインテリジェントな運用と保守

運用・保守の自動化を実現するにはどうすればよいでしょうか?つまり、さまざまな運用および保守戦略と変更は、可能な限りスクリプトまたはツール管理で実装する必要があります。これは、将来も避けられない道です。すべての企業は、これを構築するためにエネルギー、人材、および資金を投資する必要があります。これにより、多くの人件費を大幅に節約できます。

私たちはツールから自動化へと移行し、その後インテリジェンスを探求して運用保守システムの継続的な改善を促進し、ビジネス部門が認識することなく、人間の介入を必要とせずにすべての障害を事前に処理できるようになるまで続けます。そのとき、運用・保守担当者は、より予測や在庫管理の業務に注力し、ビジネス側に傾倒し、ビジネスや製品に対する価値を十分に発揮できるようになります。

これらの戦略は、データセキュリティ業界での長年の経験に基づいてまとめられており、参考になります。もちろん、これらの戦略は実際の運用環境で実装する必要があります。残りの 28 の戦略については、ビデオリンクをクリックしてください。

http://aix..com/activity/10019.html

《個人プロフィール》

北京大学理学修士の Hou Shengwen 氏は、現在、Beike のテクニカルディレクター、Oracle ACE ディレクター、Alibaba Cloud MVP、OCM Alliance の創設者、China Oracle User Group (ACOUG) のコアメンバー、China Cloudera User Group (ACCUG) の創設者、TiDB User Group TUG の共同創設者、Enmo Academy の創設者、ITPUB のシニアモデレーター、DataGURU エキスパートグループのメンバー、および「Deep Programming in SQL and PL/SQL」の翻訳者を務めています。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]