既存のデータアーキテクチャがイノベーションを阻んでいる10の兆候：パート2 #MongoDB #DataArchitecture #セキュリティ #データ侵害
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは、MongoDB社のブログで2021年12月16日に公開された「10 Signs Your Data Architecture is Limiting Your Innovation: Part 2」の日本語翻訳です。
これまでの記事はこちらでご覧いただけます：Part1
今や組織は非常に膨大な数のデータを収集・保存・分析するようになりました。これは組織がデータを監視・管理し、保護する責任がますます大きくなっていることを意味します。しかし残念ながら、多くの企業が、データの保管方法や、アクセスしているユーザーについて詳しく把握しないまま事業を行っています。それに加え、複雑すぎるデータアーキテクチャが、これらの課題をさらに解決困難なものにしています。
セキュリティの脆弱性は余計なリスクを招く可能性があり、データアーキテクチャを適切に管理していないと、重大なコンプライアンス違反を犯したり、データ侵害を受けたりする恐れがあります。これらのリスクは対処に時間とリソースがかかるため、イノベーションに対し気付かずに支払っている税金のような存在です。MongoDBではこれを、DIRT(Data and Innovation Recurring Tax、データとイノベーションに関する経常税）と呼んでいます。
我々は、このDIRTを支払わざるを得ない状況に陥っている企業に現れる10の兆候を特定しました。詳細については、弊社のホワイトペーパー、『10 Signs Your Data Infrastructure is Holding You Back』（英語）をご覧ください。また、このブログシリーズのパート1も是非ご覧ください。
このブログ記事では、セキュリティ面においてこの税を支払っていることを示す2つの徴候に焦点を当てています。
徴候その3：大規模データ侵害のリスクが目の前に
データアーキテクチャが複雑になればなるほど、対応すべき脅威ベクトルは増え、セキュリティの維持に要する時間がかかり、さらにその作業はより複雑になります。データストアやアプリケーションごとに、アクセス制御、ロールの定義、ログイン手順などといった、セキュリティフレームワークやセキュリティ要件が異なってくる可能性があるのです。データベースは、別の複数のテクノロジーやベンダーと結び付いている場合があり、そうなると、全体のセキュリティを確保するには、さらに多くの時間と複雑な対応が必要になります。
これはチームにとって当然足かせになります。実際、ITマネージャーの約30%は月に16時間以上、14%はなんと月に48時間以上もパッチの適用に時間を費やしているとの報告があります。結局、適用の対応が追い付かないことも多く、ITプロフェッショナルを対象にしたPonemon Instituteの調査によると、42%のデータ侵害は、提供されているパッチを適用していない環境への攻撃によるものだとされています。また、平均で28%の脆弱性が解決されないままの状態となっています。
MongoDBのソリューション
単一のアプリケーションデータプラットホームを活用すれば、データベースとデータサービスコンポーネントの組み合わせを一組にして、開発環境と運用/セキュリティ基盤を共通化できるため、セキュリティの確保が非常に容易になります。単一の包括的なセキュリティポリシーと実装環境も利用できるようになり、データの新しいユースケースが生まれるたびに同じ作業を一からやり直す必要がありません。監査ログとアクセスの管理が大幅に効率化されると共に、セキュリティが強化され、俊敏性が高まります。
徴候その4：コンプライアンス遵守を難しくするデータ複製
現代の組織では、どの事業部門も、パフォーマンスの最適化や顧客の要求への対応に役立つデータやインサイトにアクセスできる必要があります。しかし、ほとんどのデータはサイロ化（分断）しており、データごとに形式やアクセスの方法、権限の管理が異なります。
データのサイロ化の問題を解決するうえでよく試みられるのが、別々のニッチデータテクノロジーを用いてWebを個々のシステムごとに構築する方法です。つまり、それぞれのシステムで別々に問題に対処するのです。この方法ではデータが大量に複製されることになり、だれがどのデータのコピーを所有しているのか、そしてどのくらいの数のコピーが存在しているのかでさえ、IT部門の責任者すら把握できなくなる可能性があります。
これではセキュリティ上問題があるのは明らかです。GDPRやCalifornia Consumer Privacy Actなどの規制を遵守したり、監査に効率的に対応したりするのもきわめて困難になります。個人情報が今どこにあるか、もしくはかつてどこに置かれていたのかを、コピーがいくつあるのかもわからない状態でどうやって監査担当者に正確に説明できるというのでしょうか。
MongoDBのソリューション
まずは単一のアプリケーションデータプラットホームでサイロ化を解消します。これが実現すれば、従来ではデータの複製をせざるを得なかったユースケースの多くに対応できるようになります。そして、MongoDBを活用すれば、複数のソースでクエリを統合できるので、データを別の形式に変換する必要がありません。
このシリーズの次の投稿では、開発者がどのように時間を使っているのかという点や、彼らが最上級の機能の開発と展開に時間を充てられない場合、どういった代償を支払わねばならなくなるかという点を中心的に取り上げます。
DIRTやDIRTの軽減方法について詳しく知りたい方は、
ホワイトペーパー『DIRT and the High Cost of Complexity』（英語）をご覧ください。
ブログシリーズの続きはこちらにてご覧いただけます： Part3、Part4
