More Related Content Similar to クラウドファースト時代の多層防御を支えるID管理 (20) More from Eiji Sasahara, Ph.D., MBA 笹原英司 (19) クラウドファースト時代の多層防御を支えるID管理5. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (2)
アイデンティティとアクセス管理(1)
アイデンティティのプロビジョニング/デプロビジョニング
5
課題点 推奨事項
クラウドコンピューティングサー
ビスを採用する組織にとって、
主要な課題の 1 つは、ユー
ザーのプロビジョニング/デプ
ロビジョニングにおける安全で
タイムリーな管理である。 さら
に、企業内のユーザ管理プロ
セスに投資をした企業は、それ
らのプロセスとプラクティスをク
ラウドに広げようとする。
●クラウドサービスプロバイダーによって提供されている機能は、現
在、企業の要件を満たすために十分でない。 利用者は、クラウドプ
ロバイダー固有のカスタムコネクターの作成など、管理の複雑さをさ
らに悪化させる独自のソリューションを避けるべきである。
●利用者は、実用的な範囲において、クラウドサービスプロバイダー
によって提供された、望ましくは、SPML (Service Provisioning Markup
Language)スキーマで構築された標準コネクタを利用するべきである。
あなたのクラウドサービスプロバイダーが現在 SPML を提供しない場
合、あなたはそれを要求するべきである。
●利用者は、クラウド内のアプリケーションとプロセスを包含するよう
に、アイデンティティデータに関する信頼できるレポジトリを、変更す
るか、広げるべきである。
6. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (3)
アイデンティティとアクセス管理(2)
認証
6
課題点 推奨事項
組織がクラウドサービス
を利用し始めるとき、信頼
でき管理が可能な方法で
ユーザー認証をすること
は、重大な必要条件であ
る。組織は、認証情報の
管理、厳密認証(通常多
要素認証と定義される)、
委譲された認証(デレゲー
ション)およびあらゆる種
類のクラウドにわたる信
用情報の管理など、認証
に関する課題に対処して
いかなければならない。
クラウドサービスプロバイダーと顧客企業の両方が、認証情報管理と厳
密認証に関連する課題を検討し、リスクを適切に低減させる、コスト効
率のよいソリューションを実装するべきである。
●企業のための認証:企業は、彼らの Identity Provider(IdP)を通して
ユーザー認証を行い、フェデレーションにより SaaS ベンダーと信頼関係
を構築することを検討するべきである。
●自身の意思でクラウドを利用している個人ユーザーのための認証:企
業は、複数のサイトで有効な単一セットの認証情報の使用を可能にする
ために、Google、Yahoo、OpenID、Live ID などのユーザー中心の認証を
使用することを検討するべきである。
●認証を委譲するための独自の方法(たとえば、共有の暗号化クッキー
などの方法で信用情報を扱うなど)を要求するあらゆるSaaSプロバイ
ダーは、継続する前に適切なセキュリティ評価により厳密に評価される
べきである。一般的には、オープンスタンダードを使用するべきである。
7. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (4)
アイデンティティとアクセス管理(3)
フェデレーション (1)
7
課題点 推奨事項
連携したアイデンティティ管理は、組
織が選択したアイデンティティプロバ
イダー(IdP)を利用してクラウドサービ
スのユーザー認証を行う上で重要な
役割を果たす。そのような意味で、
サービスプロバイダー(SP)と IdP の
間でアイデンティティ属性を安全な方
法で交換することも、重要な必要条
件である。組織は、否認防止をサ
ポートしながら、アイデンティティライ
フサイクル管理や、機密性と完全性
を担保するための利用可能な認証
方法に関するさまざまな課題、およ
びそれらの課題に対処するソリュー
ションについて理解するべきである。
クラウドでフェデレーションアイデンティティ管理を検討している
組織は、アイデンティティライフサイクル管理、認証方法、トー
クン形式および否認防止に関するさまざまな課題とそれらに対
応するための利用可能なソリューションについて理解するべき
である。
●企業は、プロバイダーが主要な規格(SAML と WS-
Federation)のうち少なくともどちらかをサポートしていることを
確認するべきである。 複数の規格へのサポートは、高い柔軟
性を可能にする。
●クラウドサービスプロバイダーには、異なったアイデンティ
ティプロバイダーから標準のフェデレーション形式を受け入れ
る柔軟性があるべきである。 しかし、ほとんどのクラウドサー
ビスプロバイダーは、単一の規格しかサポートしていない。クラ
ウドサービスプロバイダーは、何らかのタイプのフェデレーショ
ンゲートウェイを実装することを検討するべきである。
8. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (5)
アイデンティティとアクセス管理(4)
フェデレーション(2)
8
課題点(再掲) 推奨事項
連携したアイデンティティ管理は、組
織が選択したアイデンティティプロバ
イダー(IdP)を利用してクラウドサービ
スのユーザー認証を行う上で重要な
役割を果たす。そのような意味で、
サービスプロバイダー(SP)と IdP の間
でアイデンティティ属性を安全な方法
で交換することも、重要な必要条件
である。組織は、否認防止をサポー
トしながら、アイデンティティライフサ
イクル管理や、機密性と完全性を担
保するための利用可能な認証方法
に関するさまざまな課題、およびそ
れらの課題に対処するソリューション
について理解するべきである。
●Federated Public SSO は、SAML や WS-Federation などのク
ラウドサービスプロバイダーの規格に基づいているが、
Federated Private SSOは、VPN上で既存のSSOアーキテクチャ
を活用する。長期的には、Federated Public SSO が理想的であ
るが、成熟した SSO アーキテクチャを持っており、クラウド展開
の数が限られている組織にとっては、Federated Private SSO の
利用は短期的なコストメリットをもたらすかもしれない。
●利用者は、トークンの発行と照合を管理することを目的とし
て、フェデレーションの導入を外部に展開するため、フェデレー
ションゲートウェイを選ぶかもしれない。この手法により、組織
は様々な形式のトークンの発行をフェデレーションゲートウェイ
に委譲し、フェデレーションゲートウェイはトークンを異なる形
式に翻訳する。
9. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (6)
アイデンティティとアクセス管理(5)
承認とユーザープロファイル管理
9
課題点 推奨事項
ユーザープロファイルとアクセス制御
ポリシーの要件は、ユーザーが自身
の意思でクラウドを利用しているの
か(利用者など)、組織のメンバーとし
て利用しているのかによって異なる。
SPI (Security Parameters Index)環境
におけるアクセス制御の要件は、信
頼できるユーザープロファイルおよ
びポリシー情報の作成、それを使用
したクラウドサービス内のアクセス制
御、およびこれらの監査可能な方法
での実施を含む。
●サービスまたはデータの種類に応じた、アクセス制御モデル
の適切性を検討する。
●ポリシーおよびユーザープロフィール情報の信頼できるソー
スを特定する。
●データに必要なプライバシーポリシーに対するサポートを評
価する。
●ポリシーとユーザー情報を規定するフォーマットを選択する。
●ポリシー管理ポイント(PAP)からポリシ決定ポイント(PDP)にポ
リシーを転送するメカニズムを特定する。
●メカニズムがポリシー情報ポイント(PIP)からポリシー決定ポ
イント(PDP)にユーザ情報を転送するメカニズムを特定する。
●ポリシー決定ポイント(PDP)からの方針決定を要求する。
●ポリシー実施ポイント(PEP) で決定した方針を実行する。
●監査に必要な情報を登録する
10. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (7)
アイデンティティとアクセス管理(6)
IdaaS (Identity as a Service)に関する推奨事項(1)
10
推奨事項
●内部の企業ユーザーに関しては、管理人は、ダイレクト VPN、または SAML (Security Assertion
Markup Language)や厳密認証などの業界基準を通して、クラウドへの安全なアクセスを提供するた
めのクラウドサービスプロバイダーのオプションを見直さなければならない。クラウドを使用すること
によるコスト削減は、従業員情報を外部に保存することに付随するプライバシー問題に対応するた
めのリスク軽減対策コストとバランスをとる必要がある。
●パートナーなどの企業外ユーザーに関しては、情報所有者は、IAM プロバイダーとのやりとりを
SDLC (Systems Development Life Cycle)および脅威の評価の中に組み込む必要がある。また、アプリ
ケーションセキュリティ(さまざまなコンポーネント間のやりとり、およびそれによってもたらされる SQL
インジェクションやクロスサイトスクリプティングなどの脆弱性)についても検討し、対策を講じる必要
がある。
●PaaS 利用者は、プロビジョニング、認証、アクセス制御ポリシーに関するコミュニケーションおよび
監査情報に関する規格について、IDaaS ベンダーがどの範囲までサポートするか調べるべきである。
11. 1-1.クラウドコンピューティングのためのセキュリティ
ガイダンス V2.1(2009年12月)とID管理 (8)
アイデンティティとアクセス管理(7)
IdaaS (Identity as a Service)に関する推奨事項(2)
11
推奨事項
●独自のソリューションは、独自コンポーネントにおける透明性が欠如することにより、クラウド上の
IAM 環境に対して重大な危険をもたらす。独自のネットワーク・プロトコル、暗号化アルゴリズムおよ
びデータ通信は、しばしばより安全が低く、脆弱であり、相互運用可能性が低い。外部化を行う IAM
コンポーネントに対してはオープンスタンダードを使用することが重要である。
●IaaS 利用者に関しては、仮想サーバを起動するために使用されるサードパーティイメージを、ユー
ザーおよびイメージの信頼性の観点で確認する必要がある。 イメージのライフサイクル管理に提供
されるサポートの検討は、あなたの内部ネットワークにインストールされているソフトウェアと同じ原
則をもとにして確認しなければならない。
28. 1-4.SecaaS(Security as a Service)導入ガイダンス
カテゴリー1:アイデンティティ/アクセス管理(2012年9月)(1)
Identity and Access Management as a Serviceの構成要素
(https://cloudsecurityalliance.org/download/secaas-category-1-identity-and-access-
management-implementation-guidance/)
28
出典:Cloud Security Alliance 「SecaaS Implementation Guidance: Category 1 // Identity and Access Management」
(2012年9月)
29. 1-4.SecaaS(Security as a Service)導入ガイダンス
カテゴリー1:アイデンティティ/アクセス管理(2012年9月)(2)
Identity and Access Management as a Serviceの要求事項
認証
強力な認証、リスクベース認証
アイデンティティ・フェデレーション・サービス
連携したアイデンティティ管理、連携したシングルサインオン(SSO)
アイデンティティ管理サービス
プロビジョニング/ディプロビジョニング、特権ユーザー管理
権限付与(承認)とアクセス管理
権限付与(承認)管理、アクセスポリシー管理、監査とレポーティング
29
30. 1-4.SecaaS(Security as a Service)導入ガイダンス
カテゴリー1:アイデンティティ/アクセス管理(2012年9月)(3)
Identity and Access Management as a Service導入の考慮点
制御
可視性と透明性
ポータビリティ
相互運用性
費用と投資の考慮
マルチレイヤ管理
パフォーマンス/可用性の考慮
サービスレベルアグリーメント(SLA)
ハイブリッドクラウド/非クラウドサービスの統合
不要なアクセス
拡張性
30
31. 1-4.SecaaS(Security as a Service)導入ガイダンス
カテゴリー1:アイデンティティ/アクセス管理(2012年9月)(4)
統合型Identity and Access Management as a Serviceの導入
31
出典:Cloud Security Alliance 「SecaaS Implementation Guidance: Category 1 // Identity and Access Management」
(2012年9月)
<AIMの概念機能アーキテクチャ> <統合型AIMaaSの導入>
40. <参考 1.>
英国「G-Cloud」フレームワークのセキュリティに関する
要求事項14原則(1)
40
原則 表題 内容
原則1 転送中のデータ
の保護
ネットワーク転送中のユーザーデータは、改ざんや傍受に対
し、適切に保護されるべきである。
原則2 資産の保護とレ
ジリエンス
ユーザーデータと保存または処理する資産は、物理的な改
ざん、損失、損害または占拠に対して保護されるべきである。
原則3 ユーザー間の分
離
悪意のあるまたは感染したサービス・ユーザーは、他のサー
ビスまたはデータに影響が及ばないようにすべきである。
原則4 ガ バ ナ ン ス ・ フ
レームワーク
サービスプロバイダーは、そのサービスと情報の管理を調整
して方向づける、セキュリティガバナンス・フレームワークを
有するべきである。このフレームワーク外に導入された、い
かなる技術的コントロールも、根底から覆されるであろう。
原則5 運 用 セ キ ュ リ
ティ
攻撃を妨害・検知・予防するために、サービスを、セキュアに
運用・管理する必要がある。優れた運用セキュリティは、複
雑、官僚的、時間の浪費、高額のプロセスを必要とすべきで
はない。
41. <参考 1.>
英国「G-Cloud」フレームワークのセキュリティに関する
要求事項14原則(2)
「G-Cloud」フレームワークのセキュリティに関する要求事項14原則(2)
41
原則 表題 内容
原則6 従業員のセ
キュリティ
信頼するのに高い信頼性が必要なデータやシステムに、
サービスプロバイダーの従業員が、アクセスするところ。適切
なトレーニングによりサポートされた審査により、サービスプ
ロバイダーの従業員による偶発的もしくは悪意のある漏えい
の可能性を少なくする。
原則7. セ キ ュ ア な
開発
サービスは、セキュリティに対する脅威を特定して低減する
ために、設計・開発されるべきである。そうでない場合、セ
キュリティ課題に対する脆弱性があって、データを漏えいした
り、サービスの損失を引き起こしたり、その他悪意のある行
動を可能にしたりすることがある。
原則8 サ プ ラ イ
チェーン・セ
キュリティ
サービスプロバイダーは、サービスが実行を要求するすべて
のセキュリティ原則を、サプライチェーンが満足のいくように
サポートすることを保証すべきである。
42. <参考 1.>
英国「G-Cloud」フレームワークのセキュリティに関する
要求事項14原則(3)
「G-Cloud」フレームワークのセキュリティに関する要求事項14原則(3)
42
原則 表題 内容
原則9 セキュアなユー
ザー管理
サービスプロバイダーは、ユーザーがサービス利用をセ
キュアに管理するためのツールを提供すべきである。管
理インタフェースと手順は、権限のないアクセスやユー
ザーのリソース、アプリケーション、データの変更を予防す
る、セキュリティの壁の重要な部分である。
原則10 アイデンティティ
と認証
サービス・インタフェースへのアクセスはすべて、認証され
て権限が付与された個人に制限すべきである。
原則11 外 部 イ ン タ
フェースの保護
サービスの外部または信頼できないインタフェースをすべ
て特定して、適切に防御すべきである。
原則12 セキュアなサー
ビス運営
クラウドサービスの運営に使用するシステムは、高い特権
が付与されたサービスにアクセスする。これらの漏えいは、
セキュリティコントロールを回避して大容量のデータを盗
むまたは操作する手段となるなど、重大なインパクトを及
ぼすことがある。
43. <参考 1.>
英国「G-Cloud」フレームワークのセキュリティに関する
要求事項14原則(4)
「G-Cloud」フレームワークのセキュリティに関する要求事項14原則(4)
43
原則 表題 内容
原則13 ユ ー ザ ー の 監
査情報
サービスへのアクセスをモニタリングする必要がある監査
記録とその中に保有するデータを提供すべきである。ユー
ザーが利用できる監査情報のタイプは、相当の時間的尺
度内で、不適切または悪意のある活動を検知して対応す
る機能に直接インパクトをもたらすことがある。
原則14 サ ー ビ ス の セ
キュアな利用
クラウドサービスとその内部に保持されるデータのセキュ
リティは、貧弱なサービスを利用した場合、覆されることが
ある。その結果として、ユーザーのデータが適切に保護さ
れるためのサービスを利用する時、一定の責任を負うこと
になる。
出典:GCHQ - NCSC「Guidance - Implementing the Cloud Security Principles」(2016年9月21日)を基に
ヘルスケアクラウド研究会作成 (2017年6月)
44. <参考 2.>
英国「G-Cloud」原則10:アイデンティティと認証(1)
44
アプローチ 説明 ガイダンス
1.サービスプロバイダーのアサーション
2.ユーザー名と
二要素認証
ユーザーは、ユーザー名
とハードウェア、ソフト
ウェアトークン、またはブ
ランド以外のチャレンジ
(例.SMS)を利用して、
認証する
認証のスキームまたは導入に脆弱性があり、
権限のないアクセスを可能にする場合がある。
標準化または保証された認証スキームは、
設計および導入が堅牢だという独立的な信
頼を与える。
3.ユーザー名と
TLSクライアント
認証
サービスは、サービスま
たは消費者組織により発
行されたTLS 1.2クライア
ント認証を利用して、認
証をサポートする
セキュリティは、セキュアな認証の管理を、消
費者エンドユーザーのデバイスに依存してお
り、プロセスが、損失したまたは危険にさらさ
れた証明書を無効にする必要がある。
認証のスキームまたは導入に脆弱性があり、
権限のないアクセスを可能にする場合がある。
45. <参考 2.>
英国「G-Cloud」原則10:アイデンティティと認証(2)
原則10:アイデンティティと認証(2)
45
アプローチ 説明 ガイダンス
4.認証のフェ
デレーション
サービスは、企業の
ディレクトリ、OAuth、
SAMLプロバイダー
など、他の認証ス
キームとの連携をサ
ポートする
連携したアイデンティティソリューションは、ソースのア
イデンティティソリューションのリスクを取得する。ソー
スのアイデンティティソリューションが危険にさらされた
ことによって、連携したアイデンティティが保護する、あ
らゆるリソースへのアクセスを与える。
5. 特 定 の リ ン
ク 、 企 業 ま た
はコミュニティ
ネットワーク上
の制限された
アクセス
サービスへのアクセス
は、PSN、物理的また
は暗号学的保護下に
ある企業ネットワーク、
物理的または暗号化さ
れたトンネルのような
保護ネットワークに限
定される
インタフェースが、プライベートまたはコミュニティネットワーク
を介してのみアクセス可能なら、盗まれた証明書を利用する
機会は減少する。
ネットワークのユーザーまたはアクセスする攻撃者は依然と
してサービスに到達できるので、何らかの認証が要求される。
ネットワークが大きければ大きいほど、潜在的攻撃を受ける
人口は大きくなり、認証要件はより強くなる。非常に規模の大
きいネットワークは、通常、パブリックと同様に扱われるべき
である。
ネットワークのすべての合法的ユーザーにアクセスが認めら
れているとしても、監査目的のためにユーザーを特定するこ
とが適切な可能性がある。
46. <参考 2.>
英国「G-Cloud」原則10:アイデンティティと認証(3)
原則10:アイデンティティと認証(1)
46
アプローチ 説明 ガイダンス
6.ユーザー名とパ
スワード
認証は、基本的なユー
ザー名とパスワードに
よるものであり、消費者
に強力なパスワードの
選択を強制する機能は
ない
強力なパスワードまたはパスフレーズの選択を強制す
る機能がないと、ユーザーが、力づくの攻撃に対して脆
弱なパスワードを選択する可能性がある。ユーザー名
およびパスワードは、エンドユーザーデバイス上のフィッ
シングやマルウェアを介して危険にさらされやすい。認
証における第二の要素の欠如は、後々、サービスにア
クセスする攻撃者が利用可能であることを意味する。暗
号化されていないチャネル上を通る証明書は、公衆wi-
fiホットスポットなど、セキュアでないネットワーク上で傍
受される特定のリスクがある。
7. ユーザー名と強
力なパスワード/
パスフレーズの強
制
認証は、ユーザーによ
る強力なパスワード選
択の強制をサポートす
るサービスを装備した
ユーザー名とパスワー
ド/パスフレーズによる。
ユーザー名およびパスワードは、エンドユーザーデバイ
ス上のフィッシングやマルウェアを介して危険にさらされ
やすい。認証における第二の要素の欠如は、後々、
サービスにアクセスする攻撃者が利用可能であることを
意味する。暗号化されていないチャネル上を通る証明
書は、公衆wi-fiホットスポットなど、セキュアでないネット
ワーク上で傍受される特定のリスクがある。
58. 3-1. 英国医療界:プレシジョン・メディシンの事例(8)
英国保健省「ゲノミクス・イングランド」(4)
情報セキュリティの責任分担 ⇒ 多層防御エコシステムの組織的対策
上級情報リスクオーナー(SIRO: Senor Information Risk Owner)
情報ガバナンス・リード(IG Lead)
情報資産オーナー(IAO: Information Asset Owner)
ラインマネージャー(*非常勤スタッフ、外部委託先の管理責任を担う)
全スタッフ など
ポリシー集
情報ガバナンス管理フレームワークとポリシー
機密保持とデータ保護ポリシー
情報セキュリティポリシー
情報品質および記録管理ポリシー
データアクセスおよび許容される利用ポリシー など
58