Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
「Azureのセキュリティと言っても範囲が広すぎるので、
どこから手を付けたら良いのか分からない!」
という方のためのセッション
CI17
自己紹介
本セッションについて
機密性その情報を知る必要があるユーザー
のみがデータにアクセスできること
アクセス権の管理
データの暗号化
完全性情報が適切に処理され、
データが不正に変更されないこと
トランザクションの制御
デジタル署名
可用性システムが安定的に稼働し、
データがいつでも参照できること
災害対策(Disaster Recovery)
バックアップ
セキュリティの三要素
TrustedProductiveIntelligentHybrid
お問い合わせの多いご質問の傾向
オンプレミスとクラウドの違いとは何か?
実装方法
サービスの質問 使い方の質問 サード パーティ製品
お問い合わせの多いご質問の傾向
オンプレミスとクラウドの違いとは何か?
実装方法
サービスの質問 使い方の質問 サード パーティ製品
セキュリティのカテゴリーの関係性
インシデントレスポンス
オンプレミスと Azure の大きな違い
アプリ担当
ミドルウェア担当
OS 担当
仮想化基盤担当
ネットワーク担当
アプリ担当
ミドルウェア担当
OS 担当
仮想化基盤担当
ネットワーク担当
マイクロソフトと作業と責任を分担する
Azure の中の人の対応状況を確認する
https://blogs.msdn.microsoft.com/appserviceteam/2018/01/18/demystifying-the-magic-behind-app-service-os-updates/
サービスと作業
ネットワークの制御 可能 可能 インターネットのみ
TLS/暗号スイート OS の設定でフルカ
スタマイズが可能
限定的に可能 TLS のみ可能
セキュリティ
アップデートの作業
ユーザー マイクロソフト マイクロソフト
運用コスト 大 中 小
マイクロソフトに任せるか?自分で実装するか?
サービスと作業
ネットワークの制御 可能 可能 インターネットのみ
TLS/暗号スイート OS の設定でフルカ
スタマイズが可能
限定的に可能 TLS のみ可能
セキュリティ
アップデートの作業
ユーザー マイクロソフト マイクロソフト
運用コスト 大 中 小
マイクロソフトに任せるか?自分で実装するか?
• システムに関わる人・アプリと役割の定義
• 役割に応じた適切な権限の設定
• ID とアクセス権の集中管理
• 強固な認証方式の提供
ID とアクセス管理
データの管理
ネットワーク
機密性・完全性への対応
ID とアクセス管理
• 機密データの検出とラベリング
• データを安全に制御
• 暗号化
• 不正なプログラムからの防御
データの管理
ネットワーク
機密性・完全性への対応
ID とアクセス管理
データの管理
• イントラネットとインターネットの境界
• アクセスを許可するポートの制御
• 通信を許可するアプリケーションの識別
• 通信の暗号化
ネットワーク
機密性・完全性への対応
Azure
Virtual Network
Azure
Express Route
Network
Security Group
Azure
Application Gateway
• ID 基盤の冗長化
ID とアクセス管理
• 複製、バックアップ機能の利用
データの管理
• 複数リージョンとの接続
• リージョンを超えたロード バランシング
ネットワーク
可用性への対応
Azure Backup
Azure AD
Azure
Traffic Manager
Azure
VNET Peering
Azure
VPN Gateway
セキュリティの三要素が満たされた状態を保つ
ID とアクセス管理
データの管理
ネットワーク
• 構成情報、変更の監視
構成の標準化
• 構成変更・アクセス ログ
行動の記録と監査
• 関係者への報告
• インシデント対応
インシデント レスポンス
CIS Microsoft Azure Foundations Security Benchmark
https://azure.microsoft.com/en-us/resources/cis-microsoft-azure-foundations-security-benchmark/
サード パーティ製品の利用
192.168.0.0/24 からの
Web アクセスのみ許可
192.168.0.0/24 内の PC
インターネット
HTTP/HTTPS OK
RDP NG
全ての通信 NG
Demo
デモ環境で検出された主な脅威
オープン API プラットフォーム“Resonatex” を例にしたクラウド セキュリティの考え方
CI17
Resonatex とは
金融機関をはじめとした様々な企業体のオープン API を
セキュアに公開。
API 利用企業と API 提供企業をつなぎ、API エコノミーの
実現を支援するオープン API プラットフォーム サービス。http://www.unisys.co.jp/news/nr_170926_resonatex.html
Resonatex とは
地公体金融機関A 異業種
Fintech 異業種 IoT・Big DataAPI 利用
サービス
エンド ユーザー(消費者・企業)
自社アプリ
API 公開
プラット
フォーム
API 提供
サービス
共通アカウント”AduME”
認可エンジン
所有権管理(オーナーシップマネジメント)
「ResonatexTM」
金融機関 B
• Microsoft Azure プラットフォーム上にセキュアな VNET を構成
• その中に IaaS(Virtual Machines)で機能構築 +
いくつかの PaaS(API 管理:Azure API Management、
OAuth 2.0 認可:Authlete 等)を利用
• API を公開する企業群とは閉域ネットワーク(ExpressRoute)で接続
Resonatexのシステム構成
• スピード・コスト・セキュリティ、そのためのクラウド
• インターネット上の脅威、より優れた技術、凄まじいスピードで進化
• 変化の激しい分野においては、オープン イノベーションの考え方で
よりよいものを組み合わせ、進化させつつ対応していくことが最適解
自前主義はナンセンス
• そもそも API はオープン イノベーションのための実装技術
そのためのプラットフォームで全自前主義で頑張っても無意味
なぜ Resonatexはクラウドなのか?
• ネットワーク セキュリティの観点から見ると、Resonatex はいわば
企業システムとインターネットの境界面・セキュリティ防護層
• セキュリティ実装の詳細は、残念ながら公開できませんが。。
金融機関に求められるレベルのセキュリティ要件をベースに、
Azure で提供されるもの、その他のもの、色々と組み合わせて実現
Resonatexのセキュリティ
① オンプレでのベスト プラクティスはそのままでは通用しない• 例えば。。
IPS はオンプレではインライン接続で設置するのが定石だが。。
クラウド上でのセキュリティ確保の留意点
Internet 内部 NetworkIPS/IDSFirewall
① オンプレでのベスト プラクティスはそのままでは通用しない• クラウドの場合、物理的な「インライン」設置は不可
➢インライン接続的な動作を実現するため、外部からの通信を
一旦 IPS にルーティングした上で内部 NW に流す構成とした
クラウド上でのセキュリティ確保の留意点
Internet 内部 NetworkIPS/IDSFirewall
② PaaS には注意• 運用・保守を気にすることなく機能利用できる PaaS は非常に便利
• 一方、種々の制限/落とし穴もある たとえば。。
クラウド上でのセキュリティ確保の留意点
② PaaS には注意(つづき)• セキュアな VNET を構成しても、PaaS の DB サービスである
Azure SQL Database はその VNET の中に置けなかった(※次ページ注)
Azure SQL Database としても種々のセキュリティ対策は可能だが
それだけでは要件に合わない場合は IaaS で実装要
クラウド上でのセキュリティ確保の留意点
セキュアな内部 Network
…
③ でもクラウドはどんどん進化します• どんどん新しいサービスができ、既存サービスも改善されていく(改悪/廃止もままある。。)
• 前ページ記載の 「SQL Database を自 VNET 内に置けない問題」 も
今年になってある程度解決
➢クラウドにおけるベスト プラクティスはどんどん変わっていくため
常に動向に注意し、上手く対応していくことが重要
クラウド上でのセキュリティ確保の留意点
まとめ:実践していただきたい事
© 2018 パロアルトネットワークス株式会社 All rights reserved.
本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。
本情報の内容 (添付文書、リンク先などを含む) は、de:code 2018 開催日 (2018年5月22~23日) 時点のものであり、予告なく変更される場合があります