「データエンジニアリングの基礎」を読もう 10章 セキュリティとプライバシー

本記事の位置付け

下記読書会のための要約です。
https://gaisaba.connpass.com/event/334166/

課題図書

翻訳版

英語版

もともとは英語版をじっくり読むスタイルの読書会でしたが、進めているうちに翻訳版が出たことや、内容全体を早めにキャッチアップしたいことから、今は翻訳版を1章ずつ読み進めています。

今回の範囲

10章 セキュリティとプライバシー

要約

冒頭（全体像）

• セキュリティの重要性の再確認
• 日々のワークフローに取り入れられる簡単なプラクティスの紹介

をするよ！

ありがちな話

• セキュリティの重要性をみんな認識はしている
• でも実装は後回しにする

本来は、セキュリティ・ファーストで設計・実装を進めるべき。

プライバシー関係の法令

• FEPRA
  • Famili Educational Rights and Privacy Act
  • 家庭教育の権利とプライバシーに関する法律（1970年代制定）
• HIPAA
  • Health Insurance Portability and Accountability Act
  • 医療保険の携行性と責任に関する法律（1990年代制定）
• GDPR
  • EU一般データ保護規則（2010年代）

これらの法律に違反した場合のインパクトは重大。

10.1 人材

人が最大のセキュリティホール！

10.1.1 ネガティブ思考の力

• 最悪のケースを想定する
• センシティブなデータを保護する最善の方法は、取り込まないこと

10.1.2 常に心配性でいる

• 認証情報、機密情報、機密データの要求に安易に応じない
• プロジェクトのデータの扱いに倫理的に問題がないか自問する

10.2 プロセス

セキュリティを習慣化しよう！

10.2.1 劇場型セキュリティ vs 習慣としてのセキュリティ

劇場型セキュリティとは、「セキュリティ対策やってます感」を出すためのセキュリティ対策、的な意味であるもよう。

セキュリティは、組織全体で習慣化できるほどシンプルで効果的でなければならない。

悪い例（劇場型セキュリティ）

• 誰も読まない数百ページのセキュリティポリシー
• すぐにわすれてしまう年1回のセキュリティポリシーの見直し
• セキュリティ監査のチェックボックスのチェック

良い例（筆者の会社で実践していること）

• 少なくとも月1回のセキュリティトレーニング、ポリシーの見直し

10.2.2 アクティブセキュリティ

変化する世界におけるセキュリティの脅威について考え、研究すること。

例：成功したフィッシング攻撃を研究し、組織のセキュリティ脆弱性を熟考して能動的なセキュリティ体制をとる

10.2.3 最小権限の原則

悪い例

• 本当に必要なロールは一握りなのに、そのユーザーに管理者権限を与える

ぐさぐさぐさっ（プリセールスあるある）

良い例

• ユーザー（もしくは所属グループ）には必要なときに必要なだけのIAMロールを提供する。
• ロールが不要になったら削除する
• サービスアカウントも同様に運用する

必要な権限とデータだけを、必要なときに、必要な期間だけ与えましょう！

プライバシーへの配慮

• 行、列、セル単位でのアクセス制御を実施すべし

保護ガラスを割るプロセス（broken glass process）

• 保持しておかなければならないが、緊急時のみアクセスできるべきデータの管理
• 緊急承認プロセスを経た上でアクセスを許可し、作業完了後、権限をただちに取り消す

10.2.4 クラウドでの責任共有

こういうやつ⬇️

クラウドのセキュリティ侵害の大半は、クラウドではなくエンドユーザーによって引き起こされている。意図しない設定ミス、見落とし、ずさんな管理によって。

ぐさぐさぐさっ。。。

10.2.5 常にデータのバックアップをとる

自然災害によるデータの消失だけでなく、ランサム攻撃の備えとしてもバックアップが必要。

10.2.6 セキュリティポリシー

本文で筆者が推奨するセキュリティポリシーの例が挙げられている。
ポイントは「シンプルイズベスト」。

認証情報

• SSO と 多要素認証
• 認証情報を共有しない
• 古い認証情報を無効にする、できれば削除する
• 認証情報をコードに書かない

デバイス保護

• 従業員が使用する全デバイスをデバイス管理
• 全デバイスで多要素認証
• デバイスのサインインに会社の電子メール認証情報を使用
• デバイスから目を離さない
• デスクトップ全体の画面共有を避ける
• ビデオ通話の際に do not disturb モードにする

下二つは、意図しない形での画面共有による情報漏洩を防ぐため。

ソフトウエアアップデート

• アップデートのアラートがでたらブラウザを再起動
• 会社と個人デバイスのOSのマイナーアップデートを実施
• OSの重要なメジャーアップデートが出たら、アップデートに関するガイドを提供する
• OSのベータ版は使わない
• 新しいOSのメジャーバージョンが出たら、アップデートせずに1〜2週間待つ

アップデートに関する方針が具体的でとてもわかりやすい。

10.3 テクノロジー

10.3.1 パッチとシステムアップデート

OSなど

• パッチは常に当てよう
• 新しいアップデートが利用可能になったらアップデートしよう

自分のコード

• ビルドの自動化 or リリースや脆弱性に関するアラートの設定

10.3.2 暗号化

保存時の暗号化

• ストレージのデータは、バックアップやアーカイブも含めてすべて暗号化しましょう。
• アプリケーションレベルでの暗号化もしましょう。

転送時の暗号化

• 最近のプロトコルでは、転送中のデータはデフォルトで暗号化されるが鍵の扱いには注意しよう
• バケットのアクセス権限が一般公開されたままでは、転送中のデータ暗号化には何の意味もない
• 古いプロトコルのセキュリティの限界を知ろう（例：FTPは公衆ネットワーク上の通信、中間者攻撃に対して脆弱）

10.3.3 ロギング、監視、アラート

アクセス、資源利用量、課金、余分なアクセス権限についてログをとり、アラートを設定しておこう。
ユーザーまたはサービスアカウントが一定期間使っていないアクセス権限を監視するツールも増えている。

10.3.4 ネットワークアクセス

筆者が実際に目にした悪い例

• 一般公開しているS3に機密情報を入れる
• EC2のSSHを 0.0.0.0/0（インターネット上の全IP） に許可
• データベースのアクセスをインターネット上のすべてのノードから許可

ゼロトラスト vs 境界型

筆者は、ほとんどの組織にとってクラウドの方が安全と信じている。（ゼロトラストで、すべての操作に認証が必要だから）
とはいえ、セキュリティ境界を固めることに意味がある場合もある。（エアギャップ環境など）
ただし、エアギャップは人間を介した攻撃には脆弱であることを覚えておこう。

10.3.5 低レイヤデータエンジニアリングにおけるセキュリティ

あらゆる要素のセキュリティへの影響を考慮しよう

より低レイヤのセキュリティリスクとして、例えば以下が考えられる。

• ログ出力ライブラリの欠陥によるアクセス制御や暗号化のバイパス
• 機密データがメモリやCPUキャッシュに置かれている際に脆弱性にさらされるリスク

内部のセキュリティリサーチ

• 技術部門の社員には、それぞれの専門領域がある（逆に、その外の範囲は専門外となりがち）
• 技術部門の従業員全員がセキュリティ問題について考え、積極的に関与するように推奨しましょう

結論

セキュリティは、心構えと行動の習慣であるべき。
データをスマホや財布と同じように扱うべし。
基本的なセキュリティプラクティスを知り、セキュリティを常に念頭に置いてデータセキュリティ侵害のリスクを減らしましょう！

最後に

こちらの読書会も、今日で最終回となりました。

途中で何度も挫折しそうになりましたが、みなさんのおかげで最後まで読み通すことができました。

本当にありがとうございました！！