JICS2013レポート(2) 3/4午後 Enterprise Sessions

AWSセキュリティープロセス概説

  • クラウドネイティブサービス
    • 必要な機能をサービスとしてオンデマンドに利用
    • 専用線接続、VPN接続: インターネット接続だけではない
    • スケールに応じて構成を拡張
      • DNSとWebサーバがあれば最低限は始められる
      • 10万、100万になったら、LB導入、WebとDBの分離
        • 拡張したときの図を見越してセキュリティーポリシーで運用できるのがAWS
        • マルチゾーンの設定も15分程で可能
  • 仮想クラウドのサーバ:幅広いニーズに対応
    • HPC, 料金体系、SSD、I/O能の保証
  • これまでの構成がそのまま移行できる
  • 一般的にみられる懸念事項
    • クラウドに関して心配なことは?(テックターゲット)
    • 情報漏洩、不正アクセス、他社データとの隔離、社外にデータを置くことへの抵抗
  • AWSのセキュリティーの実際
    • 梅谷(うめがい)さん
  • AWS Security Model Overview
    • 第三者認証、責任共有モデル(顧客とAWSで同共でつくり上げる)
    • 物理的、AWS管理者アクセス、VM、ネットワーク
  • 責任共有モデル
    • AWSと顧客の責任分担の線引き
    • 柔軟な選択 → 顧客の責任範囲
    • 顧客側の例: サブネット構成、firewall設定
  • AWS Security Center
    • Security White Paper
    • Risk, Compliance White Paper
    • 定期的に更新
  • 第三者認証: AWSで取得している認証
    • ISO 27001(ISMS), PCI DSS L1, SOC1/SOC2, SOX, FISMA, HIPAA
    • ISO 27001: AWSのインフラ、全世界、すべての地域のDCが取得している
  • 物理セキュリティー
    • non-descript facilities: 一見してAWS DCとはわからない。看板を出さない。場所を教えない
    • 周囲に対する堅牢な管理
    • 厳格に管理された物理的アクセス
    • 2つ以上のレベル・要素による認証(それ以上の場合もある)
    • すべてのアクセスはログされ監視される
  • EC2セキュリティー
    • ホストOS
      • 特定の管理用サーバーから個別のSSHキーによるログイン
      • すべてのアクセスはログされ監査される
    • ゲストOS
      • 顧客がroot権限を持ち管理
      • AWS管理者はログイン不可能 → 「なんとかしてください」と言われてもできない
      • アクセスには顧客自身で作成したキーを使用
    • firewall
      • inbound: default deny
    • サインドAPIコール
      • X.509証明書、もしくは顧客の秘密鍵が必要
  • ネットワークセキュリティー
    • DDoS対策
      • 標準的な緩和技術を施行
    • MITM (Man in the Middle)
      • すべてのエンドポイントはSSLで保護
      • EC2のホストキーはブート毎に生成・更新
    • IPスプーフィング
      • OSレベルで不強
    • ポートスキャン禁止
    • パケットスニッフィング
      • プロミスキャス・モードは不許可にしている(パブリッククラウドなので)
      • ハイパーバイザーレベルで制御

クラウドサービスとしてのdigital identity

  • Active Directory ドメインを使っている人
    • 中央システムとして、一部システムで〜 パラパラ 〜1/10以下
    • AD: 昔はディレクトリサービスだった。2008年以降、ソリューション全体を指す
      • ディレクトリ部分は「ADドメインサービス」
      • 他にAD ligtweight directory service (LDS) 単なるLDAP、証明書サービス、rights management service (RMS)
    • ADFS federation service: identity federation 2003R2以降でサポート 〜 いまだ浸透していない
  • サービスあるところIdPあり
    • サービス(Service Provider: SP)には認証と認可がつきもの
    • Facebook, Windows Live, google, Salesforce, MS Office 365
    • これまでオンプレミスで増えてしまったIdPをどうするか? → パブリッククラウドでもくり返すのか??
      • くり返されると困る
    • オンプレミスでは乱立をどう回避したのか → 回避は……できませんでした……
      • いままでの対拠
        • 統合認証: ひとまず一か所に集めてIdPで認証(SSOできるかどうかとは別)
        • 同期: 集め切れないものはメタデータ(人事データ等)から同期する
      • これをそのままクラウドに持っていくのはどうかと
  • クレームベース(認証と認可の分離)
    • 認証側と認可側に分離することが大前提。分かれていることが重要
    • IdP: ユーザー認証、デバイス認証を行いトークン(assertion)を発行
    • SP: トークンから本人を識別し、ロールを決定してアクセスを認可
    • クレームとは「要求」のこと「これこれの情報を持って来い。うちが信頼しているIdPからでよろ」
    • ユーザーはクレームを持ってIdPへ行く。IdPが認証を行う。トークン(署名済)にクレームを入れて渡す → SPはトークンを解析してクレームを取得。本人識別、ロール決定、アクセス認可
      • IdPの認証結果に応じてSP側でロールを再計算可能
    • SPにトークンを渡すのはユーザーであるのも重要。IdPとSP間は直接通信をする必要がない → SPからIdPに「これホント?」と聞きに行く必要がない
  • クレームベースのメリット
  • SaaSとしての認証Hub
    • マルチテナント
    • 複数の認可プロトコルに対応
    • 外部IdPとのフェデレーション
    • アプリケーションはIdPを意識する必要はない(統一フォーマットのトークンだけ知っていればOK)
  • 会場でフェデレーション導入されている方 → ほとんどいない
    • SEが理解できない → ローカル認証で行っちまえ、ってなっちゃってる
  • ADの3形態
    • オンプレミス: Server AD
    • IaaS: Server AD on Azure VM
    • SaaS: Azure AD
  • Directory
    • マルチテナントに対応したディレクトリサービス
    • AD LDS: ようするにLDAP
    • オンプレミスADとの同期、フェデレーションが可能
    • 多要素認証
  • Access Control
    • 外部IdPとのIDフェデレーション
    • OAuth 2.0, OpenID (Connectは予定), SAML 2.0, WS-Federation
    • ユーザメリット: どのIdPでログオンしてもアプリが使える
      • devメリット: Access Control用のコードを1種類書けば自動的にすべてのIdPに対応
    • WAAD, SAML/P
  • Graph API
    • Odata V3
  • オンプレミスADとの同期
    • すでにオンプレミスSSOができている場合
    • Azure ADと同期(Graph API, PowerShell, DirSync, Forefront Id Manager)
    • 利点: 管理すべきリポジトリはオンプレミスのServer ADのみ
  • まとめ
    • Id federationを正しく理解しましょう
    • public cloudのIdPをうまく使うには
      • アプリをクレームベースに対応
      • アプリとの互換性を確認
      • 運用をイメージする

感想

  • AWSは各国ごとに違う法律への対応どうしているのだろうと思っていました。米国ガバメント用にデータセンターを分けている、などはスケールメリットのひとつかな、と思います。
  • 安納さんのお話はすごく勉強になりました。各技術がつながって全体としてどうなっているかわかりやすかったです。