【レポート】ML Security on AWS #AWSSummit

AWS Summit Tokyo 2019

#イベントレポート

#Amazon SageMaker

#Amazon Machine Learning

#機械学習

#AWS

カトアキ

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、加藤です。

AWS Summit Tokyo 2019 3日目に行われたセッション「ML Security on AWS」のレポートを書きましたのでご覧頂ければと思います。

登壇者

アマゾンウェブサービスジャパン株式会社

技術統括本部

ソリューションアーキテクト

志村誠

機械学習を活用するシステムが増えるにつれ、セキュリティを考慮した形で機械学習の開発・運用プロセスを回すかというのが、さまざまな組織で課題となってきつつあります。本セッションでは、機械学習でもちいるデータの権限管理、プライバシーを考慮したデータの持ち方、またデータのラベリング・学習・推論を AWS 上でセキュアに実施するための方法についてご紹介します。

レポート

機械学習プロセスにおけるセキュリティのポイントとして、考慮すべき５つの項目がある
1. 保存のデータ暗号化
2. 通信のデータ暗号化
3. 権限管理
4. 閉域に閉じた環境
5. ガバナンス

なお、セキュリティを担保することだけを考えるのではなく、担保した上で「いかに生産性を上げるか」がこのセッションでのお話のポイントである

保存のデータ暗号化について
- S3とかGlacierとか、それぞれのサービス内に配置されたデータを暗号化しておくべき
- AWS Key Management Serviceを利用
- 各暗号化方式のメリットデメリットを考慮して、採用する方式を決める
- 基本的に鍵管理方式ではSSE-KMSを使うのが最もお勧めである。
- 鍵管理方式の種類について。
- 暗号化を行う側によって分類すると次の通り
- クライアント側で暗号化
  - CSE-KMS
  - CSE-C
- サーバ側で暗号化
  - SSE-S3（Amazon S3のビルトイン機能を使う場合）
    - S3の所定の設定画面でチェックつけるだけで暗号化ができる
    - 一歩弱いところがある。S3へのアクセスができさえすれば、S3の鍵を使って復号化できてしまうということになるため。
  - SSE-KMS（AWS Key Management Serviceを使う場合）
    - S3ではなくて、ユーザ側で管理している鍵を使う
    - これが一番おすすめ。
    - S3の鍵が入手できたとしても復号できない
    - 二重のプロテクトということになる
  - SSE-C（カスタムのKey Management Serviceを使う場合）
    - 基盤をこちらで管理しないといけないという点で運用の負荷が高い

通信のデータ暗号化について
- Load Balancerからの通信をTLSで暗号化するなど、あらゆる箇所で通信を暗号化する
- VPCエンドポイントの利用

権限管理について
- データに対する最小権限の法則に沿うべき
  - 最低限の権限セットを付与し、必要に応じて権限の追加を行う
  - 定期に権限を確認
  - 本当に必要な権限だけを定義するには・・・
    - そのAWSサービスでどんなアクションがサポートされてるか理解
    - あるタスクを実行するのに必要なAPIアクションを特定
    - それらのアクションを実行するために必要な権限を特定
- クロスアカウントでの環境分離を行う
  - データ加工・管理、開発、本番でアカウントを分離し、必要なデータはコピーするか、クロスアカウントでアクセスするようにする
  - 用途や組織に応じでアカウントごと、バケットごと分離する
  - IAMポリシー、S3バケットポリシーでアクセス制御を実施する
- データの分類と前処理
  - 分析に影響ない範囲で加工して、リスクを低減する
  - 必要がなければ、そもそも取り扱わない
    - データの種類とリスクと対応
      - パーソナルデータ（リスク高い）
        
        対応としてハッシュか、数値の丸めなどをしておくことで、匿名化データに
      - 売り上げ・取引先データ（リスク中）
        
        リスク取引先名でなくIDでのみ使用するなどして。匿名化
        
        機微性を一段階引き下げる
      - 一般データ（リスク低い）

閉域に閉じた環境について
- まずリスクによるデータ分類に応じて、保護のレベルを変える
  - 高リスクデータ→機微性が高いので閉域の閉じた環境で扱うべき
    - 例えばどんなデータ？
      - 学習・推論で使うデータ
      - 学習済みモデル
  - 低リスクデータ
    - 例えばどんなデータ？
      - ログ。学習・推論時などの
      - 学習・推論のコンテナイメージ
- 特に高リスクのデータは、VPCから閉域網に閉じた形で必要なサービスのエンドポイントにアクセスするようにするべき
ガバナンスについて
- ちゃんと管理してトレースできるようにすること
  - CloudWatch Logs
  - CloudTrail
  - これらのサービスを活用して、「いつ」「だれが」どんなアクセスを行ったか確認できるように。
- 環境構築プロセスの標準化
  - そもそもテンプレートを作っておいたりすれば、道を踏み外さない
  - セキュリティアモジュールを確実にインストールするために、Jupyter Nodebook起動時に自動実行するスクリプトを用意し、そこで対応するなど
- コンテナの標準化
  - 必要なモジュール入りのコンテナをあらかじめ用意しておくなど

まとめ

投影されていたスライドを参考に、Amazon SageMakerを使った環境の構成図と、前述の1-5が指していたポイントをまとめてみました。なお、この図は登壇者が作成したものではなく、あくまで筆者の個人の見解のためご注意ください。

5つのポイント

保存のデータ暗号化
通信のデータ暗号化
権限管理
閉域に閉じた環境
ガバナンス

※画像をクリックで大きく表示します。

さいごに

Amazon SageMakerを利用すれば、AWS Direct ConnectやAWS Key Management Service等を活用しつつきちんとネットワーク設定を行えば、簡単にセキュアな機械学習環境を作成できることがわかりました。今後機械学習を行う場合には、高リスクのデータも扱うようなケースでも、今回のセッションの内容を参考にセキュリティと作業効率のバランスをうまくとってやっていくようにしたいと思いました。