datatech-jpで開催中のFundamentals of Data Engineering (English Edition)読書会に向けた、「Chapter 10. Security and Privacy」のまとめ。
以下は基本的には本文の要約であり、★マークがついている部分は私のコメントや付加情報である。
security and privacy are critical to data engineering
Introduction
security is the first thing a data engineer needs to think about in every aspect of their job and every stage of the data engineering lifecycle
- セキュリティはデータエンジニアリングの実践に不可欠だが、データ・エンジニアはセキュリティを後回しにしがち
- データエンジニアは毎日、機密性の高いデータ、情報、アクセスを扱う
- データエンジニアの役割と責任は組織の状況により異なる
- 小規模な新興企業
- データエンジニアがデータセキュリティエンジニアと兼務することもある
- 大企業
- 多くの場合、データエンジニアは、専任のセキュリティ担当者と協力する
- 小規模な新興企業
People
The weakest link in security and privacy is you.
- 常にデータエンジニア自身がターゲットになり得ることを意識する
The Power of Negative Thinking
- 常に最悪のケースを想定する
- ポジティブ思考が称賛される世界では、ネガティブ思考は嫌われるが、過度なポジティブ思考はロ攻撃や医療緊急事態の可能性を見えなくし、備えを妨げるという見方もある
- ★『最悪の事故が起こるまで人は何をしていたのか』
Always Be Paranoid
- botやハッカーが機密情報やクレデンシャルを狙っている
- オンラインでもオフラインでも、すべての行動で防御の姿勢をとるべき
- プライバシーと倫理を尊重するための最初の防衛ラインはデータエンジニア
- 自分の仕事が法的にも倫理的にも遵守されていることを確認する
- 誰かに認証情報を要求されたら、常に注意を払う
- 資格証明書の提示を求められたときは、常に細心の注意を払う
- 同僚を含め、認証情報、機密データ、機密情報を要求されたら、額面通りには誰も信用しない
- ensure that your approach delivers proper security and not just the illusion of safety.
- ★リスクベースで実効性のある対策が重要ですよね
- データ基盤で個人情報や機密データを保護する最善の方法は、そもそもそのようなデータを取り込まないこと
Processes
正規のセキュリティ・プロセス(regular security processes)に従えば、セキュリティは仕事の一部になる。セキュリティを習慣化し、実効性のあるセキュリティ(real security)を定期的に実践し、最小権限の原則を行使し、クラウドにおける共有責任モデルを理解しよう
「劇場のセキュリティ」と「日常のセキュリティ」
- 劇場のセキュリティ(security theater)
- 社内規則や法律、標準化団体の勧告（SOC-2, ISO 27001など）を重視する一方で、潜在的なリスクシナリオへの注意が不十分
- 一見セキュリティが保たれているように見えて、数分考えれば分かるような欠陥が多々ある
- ★運開分離、境界型セキュリティ...etc
- ★ランサムウエア攻撃に遭った徳島・半田病院、被害後に分かった課題とは
- 一見セキュリティが保たれているように見えて、数分考えれば分かるような欠陥が多々ある
- 誰も読まない数百ページのセキュリティポリシーや、形式的な監査、セキュリティチェック
- セキュリティは、組織全体で習慣化できるほどシンプルで効果的でなければならない
- 社内規則や法律、標準化団体の勧告（SOC-2, ISO 27001など）を重視する一方で、潜在的なリスクシナリオへの注意が不十分
- 日常のセキュリティ(security habit)
Active Security
- アクティブ・セキュリティは、ダイナミックに変化する世界におけるセキュリティの脅威について考え、研究すること
最小権限の原則
- 最小権限の原則とは、人やシステムには、目の前のタスクを完了するために必要な権限とデータだけを与える考え方
- クラウドでよく見られるアンチパターンとして、一般ユーザーにすべての管理者権限を与えてしまいがち
- 誰かに無制限の管理者アクセス権を与えることは、大きな間違い
- ユーザー（または所属するグループ）やマシンが仕事をするのに必要な権限とデータだけを、必要なときに必要な期間だけ与える
- 必要なときに必要なIAMロールを提供する。これらのロールが不要になったら、それらを取り上げる。
- 人間もマシンも同じように扱う
- あなたのユーザーや顧客は、機密データが必要なときだけ参照されることを期待している
- 機密データの列、行、セルレベルのアクセス制御を導入する
- PIIやその他の機密データのマスキングを検討し、閲覧者がアクセスする必要のある情報のみを含むビューを作成
- ★能動的なSensitive Data Detectionも併せてやるとより効果的か
- データアクセスをガラス張りにする(behind a broken glass process)
- 緊急時のみアクセスできるようにする
- 問題の解決や重要な履歴情報の照会など、緊急の承認プロセスを経た後でなければ、ユーザーはデータにアクセスできないようにする
- 作業が完了したら、アクセス権を即座に取り消す
Shared responsibility in the cloud
- クラウド・ベンダーは、そのデータセンターとハードウェアの物理的セキュリティを確保する責任がある
- クラウドのユーザーは、クラウド上で構築・保守するアプリケーションやシステムのセキュリティに責任がある
- クラウドのセキュリティ侵害の大半は、クラウドではなくエンド・ユーザーによって引き起こされ続けている
- クラウドのセキュリティ侵害は、意図しない設定ミス、ミス、見落とし、ずさんさが原因で発生する
常にデータをバックアップする
- データは様々な要因で消失する
- ハードディスクやサーバーの故障
- オペレーションミス
- 悪意のある攻撃者によるデータのロック
- 保険会社の中には、ランサムウェアによる被害に対する保険金を減額するところもある
- ディザスタリカバリやビジネスコンティンジェンシー、ランサムウェアによる攻撃などに備えて
- 常にデータを定期バックアップする
- 定期的にバックアップしたデータの復元テストを行う
- ★「一応取ってるけど復旧できるのかわからないバックアップ」、たまに見るなぁ... スキーマが変わっていて整合性が取れなかったり、特定のベンダ製品を使わないと復旧できなかったり、取り出すのに非現実的な時間がかかったり...etc
セキュリティ・ポリシー例
クレデンシャル、デバイス、および機密情報に関するベーシックなポリシーの見本
- クレデンシャルの保護
あらゆる手段でクレデンシャルを守ること。クレデンシャルに関する基本ルールを以下に示す
- すべてにシングルサインオン（SSO）を使用すること。可能な限りパスワードを避け、デフォルトとしてSSOを使用する
- SSOでは多要素認証を使用する
- パスワードや認証情報を共有しない。これにはクライアントのパスワードや認証情報も含まれる。疑わしい場合は、報告先の担当者に確認すること。その担当者が疑わしい場合は、答えが見つかるまで調べ続けること
- フィッシングや詐欺電話に注意する。パスワードは絶対に教えないこと(ここでもSSOを優先する）
- 古いクレデンシャルは無効にするか削除すること。できれば後者
- 認証情報をコードに書かないこと。シークレットはconfigとして扱い、決してバージョン管理システムにコミットしないこと。可能であればシークレットマネージャーを使うこと
- 最小特権の原則を常に行使すること。仕事をするのに必要以上のアクセス権を与えてはならない。これは、クラウドとオンプレミスにおけるすべての認証情報と権限に適用される
- デバイスの保護
- 従業員が使用するすべてのデバイスにデバイス管理を使用する。従業員が退職した場合やデバイスを紛失した場合は、リモートでデバイスを消去することができるようにする
- すべてのデバイスに多要素認証を使用する
- 会社の電子メール認証情報を使用してデバイスにサインインする
- 認証情報と行動に関するすべてのポリシーがあなたのデバイスに適用される
- 自分のデバイスを自分の延長として扱う。割り当てられたデバイスから目を離さない
- 画面共有する場合は、機密情報やコミュニケーションを保護するために、何を共有しているかを正確に把握する。共有するのは1つの文書、ブラウザのタブ、ウィンドウだけにし、デスクトップ全体を共有するのは避ける。要点を伝えるために必要なものだけを共有する
- ビデオ通話の際は通知を切る。これにより、通話中や録画中にメッセージが表示されるのを防ぐことができる
- ソフトウェア・アップデート・ポリシー
- アップデートのアラートが表示されたら、ウェブブラウザを再起動する
- 会社および個人のデバイスで、OSのマイナーアップデートを実行する
- 会社は、重要なメジャーOSアップデートを特定し、ガイダンスを提供する
- OSのベータ版は使用しない
- OSの新しいメジャーバージョンのリリースの利用は1～2週間待つ
Technology
人とプロセスによるセキュリティ対策が完了したら、次はテクノロジーを活用してシステムとデータ資産のセキュリティを確保する方法を検討する
パッチ適用とアップデート
- ソフトウェアは古くなり、セキュリティの脆弱性は常に発見される
- オペレーティング・システムやソフトウェアには常にパッチを当て、新しいアップデートが利用可能になったらアップデートする
- 自分自身のコードや依存関係をアップデートするため、ビルドを自動化するか、リリースや脆弱性に関するアラートを設定して、アップデートを手動で実行するよう促されるようにする
暗号化
- 暗号化は、セキュリティとプライバシーを尊重する組織の基本要件である。ネットワーク・トラフィックの傍受など、基本的な攻撃から守ってくれる
- 暗号化は魔法の弾丸ではない。
- 人為的なセキュリティ侵害が発生し、認証情報へのアクセスが許可された場合はあまり有効ではない
保管時の暗号化(Encryption at rest)
- データが静止状態（ストレージ・デバイス上）にあるときは、暗号化されていることを確認する
- 会社のノートパソコンは、デバイスが盗まれた場合にデータを保護するために、フルディスク暗号化を有効にしておく
- サーバー、ファイルシステム、データベース、クラウド上のオブジェクトストレージに保存されているすべてのデータについて、サーバーサイドの暗号化を導入する
- アーカイブ目的のデータバックアップもすべて暗号化する
- 最後に、必要に応じてアプリケーション・レベルの暗号化を導入する
- ★アプリレベルの暗号化が必要な場面ってどんな時なんだろう？
通信時の暗号化(Encryption over the wire)
- 通信時の暗号化は、現在の通信プロトコルではデフォルトになりつつある
- データエンジニアは、鍵の扱いについて常に注意を払うべき。鍵の扱いが悪いと、データ漏洩の重大な原因となる
- 古いプロトコルのセキュリティ上の限界も認識しておく必要がある
- レガシー・プロトコルを使わざるを得ない場合でも、すべてが暗号化されていることを確認して使うべき
ロギング、モニタリング、アラート
- 攻撃者は、通常、システムに侵入していることを公表しない
- ほとんどの企業は、セキュリティ・インシデントについて、かなり後になってから知る
- DataOpsの一部は、インシデントを観察、検出、警告すること
- データ・エンジニアとして、自動化されたモニタリング、ロギング、アラートを設定し、システムで特異な事象が発生したときに気づくようにする必要がある
- 可能であれば、自動異常検知を設定する
監視すべき領域の例
アクセス
- 誰が、いつ、どこから、何にアクセスしているか？
- どのような新しいアクセスが許可されたか？
- 通常アクセスしない、またはアクセスすべきでないシステムにアクセスしようとするなど、アカウントが侵害されていることを示すような奇妙なパターンが現在のユーザにあるか？
- 認識されていない新しいユーザがシステムにアクセスしていないか？
- 定期的にアクセスログ、ユーザー、およびそのロールに目を通し、すべてが問題ないことを確認する
リソース
- リソース ディスク、CPU、メモリ、I/Oを監視して、通常と異なるパターンがないか確認する
- リソースが突然変化している場合、セキュリティ侵害の可能性がある
請求
- SaaSやクラウド管理サービスでは、コストを監視する必要がある
- 予算アラートを設定して、支出が想定内であることを確認する
- 請求額が予想外に急増した場合は、何者かが悪意のある目的でリソースを利用している可能性がある
- 予算アラートを設定して、支出が想定内であることを確認する
過剰なパーミッション
- ユーザーやサービス・アカウントが一定期間使用していないパーミッションを監視するツールが出てきている
- 自動的に管理者に警告を発したり、指定された経過時間の後にパーミッションを削除するように設定することができる
例えば、あるアナリストが6ヶ月間Redshiftにアクセスしていないとする。その権限を削除することで、潜在的なセキュリティホールを塞ぐことができる。将来、そのアナリストがRedshiftにアクセスする必要があれば、権限を復元するためのチケットを発行すればよい
これらの横断的なビューを得るため、モニタリングでこれらの領域を組み合わせることが最善
- データチームの全員がモニタリングを閲覧できるダッシュボードを作り、何か異常があればアラートを受け取れるようにしておく
- セキュリティ侵害が発生した場合に対処するために、効果的なインシデント対応計画を策定し、定期的にその計画を実行する
ネットワーク・アクセス
- データ・エンジニアがネットワーク・アクセスに関してかなり乱暴なことをしているのをよく見かける
- 原則として、ネットワーク・セキュリティは会社のセキュリティ専門家に任せるべき
- 実際には、小さな会社ではネットワーク・セキュリティに大きな責任を負う必要があるかもしれない
- ★個人的にはこれは反対で、適切な統制を効かせる上でも、実効性のある利活用を推進する上でも、データエンジニアがネットワークについてもある程度理解して、専門のロールと対話できるようにしておくべきだと思う。「会社のセキュリティ専門家」が専門家であるとは限らないし、仮にそうであってもデータの専門家ではないだろうし、役職上のモチベーションの違い(セキュリティ専門家はデータ活用に責任を持たないのでとにかく安全に倒したい)もあると思うので
- データ・エンジニアとして、データベース、オブジェクト・ストレージ、サーバーに遭遇する機会は非常に多いので、少なくとも、ネットワーク・アクセスの適切な慣行に沿っていることを確認するためにできる簡単な対策を知っておくべき
- 本書ではワークロードをクラウドで実行することにほぼ焦点を絞ってきた
- しかしながら、境界型セキュリティが有効な場面もある
低レイヤにおけるデータエンジニアリングのセキュリティ
No link in the chain can be taken for granted.
- データ・ストレージやデータ処理システムの中枢で働くエンジニアにとって、あらゆる要素のセキュリティへの影響を考慮することは極めて重要
- どのようなソフトウェア・ライブラリ、ストレージ・システム、計算ノードも潜在的なセキュリティの脆弱性を抱え得る
本書は、ライフサイクル全体を処理するためのツールをつなぎ合わせた、ハイレベルなデータエンジニアリングを主なテーマとしているため、技術的な詳細については他の文献を読むべし
- データエンジニア全員に、セキュリティに積極的に関与するよう促す
- システムにおける潜在的なセキュリティリスクを特定したら、緩和策を検討し、その展開に積極的な役割を果たすべき
結論
- セキュリティを心と行動の習慣にする必要がある
- データを財布やスマートフォンと同じように扱う
- 会社の直接的なセキュリティ担当者でなかったとしても、基本的なセキュリティ慣行を知り、セキュリティを常に念頭に置くことで、組織におけるデータ・セキュリティ侵害のリスクを減らすことができる
