データレイクのセキュリティ確保に関する基本原則の多くは、クラウドのセキュリティストレージコンテナを保護した経験がある人なら familiar だろう。もちろん、商用データレイクの大半は既存のクラウドインフラを基盤として構築されているため、当然ともいえる。
しかし、データレイクにはデータフィード、データ分析（データレイクハウス、サードパーティー製の分析ツールなど）といった追加要素があるため、単純なストレージコンテナを超えて、相互作用が複雑になる。つまり、膨大な保存データ、受信データ、データ間の相互作用、ネットワーク接続を要件とするアプリを大規模に保護することになる。「ビッグデータ」分析やアプリケーションが企業の財務パフォーマンスにとって重要であることを考えれば、データレイクの保護はセキュリティチームにとって最優先課題だ。
データレイクにはあまりにも多くのバリエーションがあるため、あらゆるセキュリティユースケースに対応する具体的な手順を示すことはできない。しかし、サーバー、ネットワーク、その他のITインフラコンポーネントと同様に、セキュリティ原則を概説することはできる。これらの原則は、チームが目標を理解する助けになる。そのうえで、利用可能なさまざまな選択肢を検討し、目標、原則、ポリシーと整合していることを確認する必要がある。
データレイクセキュリティの範囲
データガバナンスマネージャーはデータのアクセス、転送、保存に重点を置くが、ITセキュリティマネージャーには、インフラやツールまで含む、より広い視点が必要になる。懸念事項の範囲はベアメタルのデバイスからアプリケーション内のコードまで及ぶ可能性があるものの、現実的な範囲はより狭く、各社のデータレイクがどのように構築されているかによって異なる。
データレイクの中には、Software-as-a-Service（SaaS）モデルに近いものもある。この場合、セキュリティ機能の大半がソフトウェアに組み込まれており、ITセキュリティチームは少数の項目を確認するだけでよい。反対に、社内構築のデータレイクでは、ベアメタルのデバイスや、それらを収容する部屋・建物まで保護する必要が生じることもある。
このように実装方法には幅があるものの、ITプロフェッショナルは一般的なSaaSソリューションやベアメタルのデータセンターを保護する方法を、すでにある程度理解しているはずだ。そのため本稿では、データレイク固有の懸念に焦点を当て、次のような、一般的で十分に理解されているセキュリティ要素は扱わない：本人確認、マルウェアのスキャン、レジリエンス（バックアップなど）、ファイアウォール、ネットワーク脅威検知、インシデント対応。
「ゼロトラストセキュリティの最適なソリューション」を参照。
重要なデータレイクセキュリティの懸念：可視性と制御
データレイクには、組織が保有するすべてのデータが含まれる可能性がある。すべてのデータが1か所に集まることで、リスクは複合的に増大する。
攻撃者は、価値のある情報を抜き取るため、データレイクへのアクセス獲得に注力する。内部脅威は、アクセス権の制限を超えようとしたり、価値のある情報を不適切にダウンロードしようとしたりする。承認済みで適切なデータアクセスであっても、最高機密データや規制対象データが権限のない担当者に誤って漏えいすることを防ぐため、管理する必要がある。
不適切なアクセスを防ぐには、セキュリティチームが自社のデータとユーザーを把握し、承認済みのアクセスを定義する必要がある。適切なアクセスを実装した後は、そのアクセスをテストし、継続中のアクセスが不適切に利用されていないか監視しなければならない。
こうしたデータレイクのセキュリティ上の懸念は、可視性と制御のいずれかに大別できる。この2つの側面を習得しなければ、セキュリティの他の要素もリスクにさらされていると考えるべきだ。
データレイクの可視性
データを適切に利用するには、データセキュリティチームがまずデータを可視化できなければならない。データを把握したら、制御によって適切なアクセスを強制する。しかしその後も、制御が正しく機能していることを検証するため、セキュリティチームは利用状況を可視化する必要がある。
データレイクにおけるデータの可視性：分類
データレイク内で効果的なアクセス制御を行うには、データの分類が極めて重要になる。初期分類は取り込み元に基づいて実施できるが、最終的にはデータレイク内のファイルに含まれるデータを検査し、機密データを特定する必要がある。
データレイクごとに、組み込み機能による能力は異なる。また、別製品やサードパーティー製のアドオン製品を通じて追加機能を利用できる場合もある。これらの機能の能力もさまざまで、ファイル自体を分類できる製品もあれば、ファイルから抽出したデータに分類情報を付加するだけの製品もある。
これが何を意味するのか、次の例で考えてみよう。
- AWS
- 「アドオンサービス：Amazon Macie」を提供する。
- Macieは処理した1GB単位で課金される。
- Macieは機械学習（ML）アルゴリズムを使って文書を検索し、機密情報を特定してフラグを付ける。
- 「アドオンサービス：Cloud DLP」を提供する。
- Cloud DLPは処理した1GB単位で課金される。
- Cloud DLPは、100種類を超える組み込み識別子を検出する。
- Snowflake
- 分類はテーブルとビューに保存されたデータに適用される。
- 分類にはコンピューティングコストがかかるが、追加のライセンス料は発生しない。
- 分類では機械学習を使ってカテゴリーを提案する。
- 分類カテゴリーには次のものがある。
- 意味カテゴリー（氏名、住所、年齢など）
- プライバシーカテゴリー（意味カテゴリーのサブカテゴリー）
- 直接識別子（氏名、社会保障番号など）
- 間接識別子（年齢、性別、郵便番号など）
- 個人属性（給与、医療保険の加入状況など）
一般的なデータレイクは非常に大規模であるため、ベストプラクティスとして、データをデータレイクにロードする際に自動検出・自動分類する必要がある。分類後は、強力な制御を可能にするため、データを整理、クリーンアップ、移動することもできる。
データガバナンスの問題ではあるものの、データセキュリティチームは、データを適切に分類し、制御を確立できるよう、規制対象データをどう扱うべきか把握する必要がある。例えば、社会保障番号や欧州連合（EU）市民に関する個人情報が見つかった場合、次に何が起きるのだろうか。
Databricksは事前対応型のアプローチを推奨しており、データ取り込み時にEUの個人情報（PII）を削除するよう求めている。一般データ保護規則（GDPR）では、違反者に対して2,000万ユーロ以上の制裁金を科せるためだ。違反はデータ侵害だけでなく、データを適切に消去しなかった場合（EUの忘れられる権利に基づく場合）にも発生し得る。
企業がデータを保持すると決めた場合でも、データガバナンスによって、誰が、どのような状況で、そのデータを閲覧・検索できるかを定める必要がある。適切な取り扱いを確実にする方法の1つは、データを特定のフォルダー（Azure、Googleなど）に移動するか、制限対象データカテゴリーを付与してデータベース内でフラグを付けることだ（Snowflake、Databricksなど）。
詳細は後述するが、フォルダーレベルのセキュリティ制御は、個別に割り当て、監視、維持する必要がある、より粒度の細かいオブジェクトベースの制御（ファイル、テーブルなど）よりも、はるかにスケーラビリティに優れる。データレイクツールはカテゴリーを検出し、取り込み時にデータを移動できるため、データを迅速かつ大規模に自動分類・保護できる。
関連記事：セキュリティコンプライアンスとデータプライバシー規制
データレイク利用状況の可視性：監視とログ記録
セキュリティチームが完璧な分類と制御を設定すれば、データレイクは保護されたことになる！少なくとも理論上は。理論が実際にも機能し続けているか確認するには、セキュリティチームがユーザーのアクションとAPIを可視化する必要がある。
セキュリティチームは、データレイク環境内のさまざまなログとアラートを確立、維持、監査する必要がある。データレイクの規模を考えると、不審な活動をブロックするため、ほとんどのアラートに自動化が必要になる可能性がある。
セキュリティチームは、データレイク内の監査ログを再確認し、自チームの処理能力と予算に応じて何を有効にすべきか判断する必要がある。例えばGoogleのデータレイクでは管理者アクティビティがデフォルトで有効になっているが、ノイズとストレージ容量を抑えるため、データアクセスログはデフォルトで無効になっている。
インシデントが発生した場合、標準的なインシデント対応手順は、他のリソースと同様にデータレイクにも適用すべきだ。ただしセキュリティチームは、アラートと証拠がインシデント対応チームに正しく流れることを確認する必要がある。
関連記事：インシデント対応計画の作成方法
データレイクの制御
データガバナンスチームがデータの扱い方を決定したら、データセキュリティチームはそのルールを強制する制御を実施する。多くの場合、これらのルールは既存のITポリシーを拡張したものになるが、一部のポリシーは見直しと改訂が必要になる可能性がある。データレイクの主なセキュリティ制御は、分離、認可、暗号化、転送、保存のカテゴリーに分類できる。
データレイクの分離
セキュリティプロフェッショナルとして、ITインフラで制御・管理すべき接続数は抑えたい。多くのベンダーは、データレイク構築の最初のステップとして分離を推奨している。
ソリューションによって用語は異なるものの、データレイクは非公開かつ非表示にして、外部の第三者による不用意な検出を防ぐことができる。一部のベンダーは、セキュリティで保護された企業ネットワーク内からのみデータレイクにアクセスできるようにすることを推奨している。境界のないセキュリティが広く導入されれば、この推奨における企業ネットワークは、セキュアゲートウェイやその他のゼロトラストネットワーク構成に置き換えられる可能性がある。
データレイクと外部世界との通信を厳しく制限すれば、攻撃者によるデータ流出能力を低下させられる。ただし、内部脅威や、攻撃に成功した攻撃者によるデータ流出を抑止するため、データ損失防止（DLP）対策も確立すべきだ。
「データ損失防止（DLP）の主要ソリューション」を参照。
同様の分離制御を、クエリを実行する、組織が管理するコンピュータークラスターにも適用すべきだ。こうした制御には、セキュアシェル（SSH）とネットワークアクセスの制限などが含まれるが、これらに限らない。
Azure Private LinkとAWS PrivateLinkは、企業のリソース間にプライベートなネットワーク接続を作成し、データレイクをインターネットやその他のパブリックリソースから分離する、クラウドネイティブかつブランド化されたソリューションを提供する。もちろん、企業はさらに手間をかけ、同様の結果を得るために独自のセキュアゲートウェイを構築することもできる。
Databricksなど一部のベンダーは、こうしたセキュリティ機能の一部をデフォルトのクラスターに組み込んでいる。しかし、具体的な内容を確認し、緩和が必要な可能性のある弱点を検討する責任はセキュリティチームにある。
データレイクの認可制御
認可とは、データの分類に基づいてアクセスを制御する方法を指す。アクセスは、ユーザー、API、さらにはクエリに基づいて決定される。
現代的なゼロトラスト原則に沿って、デフォルトのデータアクセス状態は完全なアクセス拒否に設定すべきだ。アクセスは、必要性に基づいて能動的に付与しなければならない。
ユーザーがデータレイクにアクセスできるようにするため、ほとんどのデータレイクは標準的なIDおよびアクセス管理（IAM）技術と統合するが、具体的な仕組みは実装によって異なる可能性がある。各技術はさらにセキュリティレイヤーを追加し、特定のユーザー、グループ、プロジェクト、企業を特定のデータリポジトリ（フォルダー、ファイル、データ列）に関連付けられる。
関連するIAMツールの例を挙げると、
- Azure Data Lakes
- Azure Active Directory（AAD）
- Azure Security Groups
- AWS Data Lakes
- AWS Identity and Access Management
- AWS Directory Service
- DataBricks
- AzureとAWSの両方のIAMと統合
- Snowflake
- さまざまなOAuth、多要素認証（MFA）、シングルサインオン（SSO）、フェデレーテッド認証に対応
ユーザーがデータレイクに接続することを認証した後は、ユーザーに許可する接続期間を決定する必要がある。ほとんどのデータレイクでは、デフォルトのセッションタイムアウト時間を設定し、通常の企業ポリシーに合わせて変更できるようにすべきだ。ただしセキュリティチームは、長時間に及ぶデータベースクエリの途中でアカウントがタイムアウトしないよう、データサイエンティストと連携する必要がある。
データそのものへのアクセスについては、ほとんどのデータレイクが、従来のITインフラにおおむね対応する何らかの階層構造で運用されている。
一部のデータレイク（Azureなど）では、未加工データをフォルダーに格納し、共有サーバー上のフォルダーと同じように保護する。フォルダーには特定のユーザーグループ、プロジェクト、さらには特定のユーザーを割り当てることができ、サブフォルダーには親フォルダーの権限を継承させることも、固有の権限を割り当てることもできる。
割り当てられる権限には、完全な読み取り・書き込み・コピー・クエリ権限のほか、読み取り専用などの限定的な権限もある。セキュリティチームは、親フォルダーの権限とユーザーの継承が確実に機能するよう、使用するデータレイクの実装が追加の子フォルダーをどのように処理するか確認する必要がある。
その他のツール（Snowflakeなど）は、フォルダーではなく、特定のオブジェクト（ウェアハウス、データベースなど）に基づいて同様の権限を提供するため、任意アクセス制御（DAC）とロールベースアクセス制御（RBAC）を組み合わせて使用する。いずれの場合も、適切な権限が付与されるよう、ユーザーをグループまたはロールに慎重に割り当てる必要がある。
一部のツールは、プリセットされたさまざまなロールと、主体アカウント所有者に対する制限を提供する。例えばGoogleのデータレイクでは、各ポリシーがサポートする主体は1,500件に限られるが、「Actions Admin」「ApiGateway Viewer」「Monitoring Dashboard Configuration Editor」など、多数の定義済みロールが用意されている。
ADと統合すれば、こうした権限は組織の基盤となるITインフラから継承される可能性がある。ただしセキュリティチームは、以下を確認するためにこれらのロールを監査する必要がある。
- ADのロールが正しく移行されていること
- ユーザーが適切なロールに所属していること
- 適切なロールがデータレイク内の正しいデータに対応していること
「Active Directoryセキュリティツールの主要製品」を参照。
データレイクの暗号化
暗号化については、ほとんどのツールが組み込みの暗号鍵を提供するが、多くのツールはさまざまな鍵管理技術とも統合でき、組織が暗号鍵を直接管理できるようにしている。
例えば、
- AzureではAzure Key Vault技術がデフォルトで使用される
- AWS Data LakesではAWS Key Management Servicesがデフォルトで使用される
- DatabricksはAzure、AWS、顧客の社内鍵管理サービスと統合できる
- Snowflakeは秘密鍵を生成し、顧客の社内鍵管理に対応するが、最低2,048ビットのRSA鍵ペアが必要となる。
暗号化は、転送中のデータ、保存中のデータ、さらにロード用にステージングされたデータにも適用すべきだ。
セキュリティチームは、デフォルトで適用される暗号化が組織のセキュリティ基準の最低要件を満たしていることを確認すべきだ。一部のデータレイクでは、暗号化データの定期的な鍵の再生成も可能なため、このより高いレベルのセキュリティを採用するセキュリティチームは、鍵の再生成に必要な時間と発生し得るコストを確認する必要がある。
関連記事：データ使用中の暗号化でデータ流出を阻止できると企業が主張。
データレイクの転送セキュリティ
データ転送について考えるとき、主にネットワークを思い浮かべる。ほとんどのデータレイクでは、デフォルトで暗号化されたデータ転送が行われるが、セキュリティチームは暗号化が適用されていることを再確認し、検証する必要がある。
データレイクへの接続を、内部ネットワークまたはネットワークゲートウェイの単一のIPリストやIPアドレス範囲に制限することで、データレイクのネットワークへの露出を抑えるべきだ（前述の「分離」を参照）。一部のデータレイクツール（例：Snowflake）では個々のユーザーにネットワークポリシーを適用できるが、多数のユーザーやアプリケーションを抱える大規模環境で、この粒度を維持するのは難しい可能性がある。
複数のクラウドリソースに接続するツール（Databricks、Snowflake）では、アプリケーションによって自動的に確立される接続であっても、正しく設定されていることをネットワークセキュリティ管理者が確認する必要がある。また、手動で構築するプライベートネットワーク接続（例：AWS PrivateLinkなど）も存在し、接続、保護、維持は全面的に組織のセキュリティチームの責任となる。
セキュリティチームは、すべてのツールがデフォルトで暗号化通信を行うわけではないことに注意しなければならない。例えばMicrosoft Azureでは、「セキュア転送が必要」を有効にする必要があり、暗号化されていないHTTPおよびSMB接続をブロックする。
しかし、こうしたネットワーク接続に加えて、データレイクでは、API接続や特定のクエリ接続、そこから返される可能性のあるメタデータやデータベース列情報についても、セキュリティチームが検討する必要がある。多くのツールは、追加のセキュリティ機能を追加できるインターフェース制御を備えている。また、ツール自体が仲介役となり、クエリに沿ってデータを受信・転送しながら、要求元がデータに直接触れないようにする場合もある。
一部の機密データは保持され、クエリで利用できるものの、表示はできないようにされる。特定のメタデータ列は、特定の種類のデータや、結果を閲覧するユーザー分類に対して難読化するよう指定され、機密データをアスタリスクに置き換えたり、別の方法で暗号化したり、ブロックしたりできる。
転送セキュリティは、データレイクに接続されるあらゆるツールにも適用すべきだ。各データレイクツールには、データレイクに安全に接続するために固有の形式、設定、手順を必要とする専用のコネクター、API、ドライバーがある。
Snowflakeは接続を分類しており、Snowflake Ecosystemツール、Snowflake Partner接続、一般設定（診断ツール、クエリテキストサイズの上限など）、SnowSQLコマンドラインクライアント、PythonやSparkなどのその他の接続およびドライバーに分類される。セキュリティチームは、使用するデータレイクの実装における同等の接続を確認し、悪意のある接続を防ぐためにデータレイクを監視する必要がある。
データレイクの保存制御
最も一般的なデータ保存に対するセキュリティ制御は暗号化であり、これはすでに説明した。データが適切に分類されている限り、アクセス制御によって保存データへのアクセス権限の大部分を処理できるはずだ。
ただしセキュリティチームは、データレイク内にどのようなデフォルトのセキュリティ機能が存在し、何を有効にする必要があるかも確認しなければならない。例えばMicrosoft Azureは、すべてのストレージアカウントでMicrosoft Defender for the Cloudを有効にすることを推奨しており、データレイクにロードされたマルウェアを検出・排除できるようにしている。
重要なデータは通常、イミュータブルデータとして保存するよう指定できる。これにより、データレイク上のユーザー操作によって変更または削除されることを防げる。削除後の一定期間内であれば、コンテナやデータを復元できるソフトデリートのオプションも利用できる場合がある。
データは、利用状況や経過時間に基づいて、コールドストレージへの移行や削除を自動的に指定することもできる。データセキュリティチームはデータガバナンスチームと連携し、イミュータブル、ソフトデリート、コールドストレージ、自動削除に適した形で、データレイク上のデータを分類し、有効化する必要がある。
連携が必要
データレイクのセキュリティの基本は、実績のあるITセキュリティの原則、すなわち可視性と制御に基づいている。ただし、他のITインフラと同様に、具体的な実装の詳細を無視すれば、こうした原則が損なわれる可能性もある。
データレイクがより複雑になるのは、ITセキュリティチームが、他の多くのアプリケーションの場合よりも直接的に、データガバナンスやデータマイニングの専門家と連携する必要があるためだ。しかし、すべての関係者が効果的に意思疎通できれば、ガバナンスポリシーを実装し、データレイク内のデータを効率的かつ自動的に分類・保護できる。