クラウドファースト時代の多層防御を支えるID管理
•
3 likes•729 views
クラウドコンピューティング利用が拡大し、コストの低減と効率の向上が可能な時代となってきましたが、クラウドによってアウトソースされたサービス全体のセキュリティについては、企業のユーザー部門とIT部門の連携・責任分担が鍵となります。クラウドプロバイダーがクラウド基盤に対するセキュリティを強化する一方、情報漏えい、標的型メール攻撃、ランサムウェア被害などの事故を未然に防止するためには、個人認証、権限付与など、ID管理に関わる運用体制の再構築が欠かせません。本講演では、クラウド環境とオンプレミス環境が混在するクラウドファースト時代におけるツール活用について、具体的な事例を交えながら考察します。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to クラウドファースト時代の多層防御を支えるID管理
Similar to クラウドファースト時代の多層防御を支えるID管理 (20)
More from Eiji Sasahara, Ph.D., MBA 笹原英司
More from Eiji Sasahara, Ph.D., MBA 笹原英司 (19)
Recently uploaded
Recently uploaded (8)
クラウドファースト時代の多層防御を支えるID管理
- 2. AGENDA 1. クラウドセキュリティアライアンスにおける ID管理の取組 2. 重要インフラを支える クラウドファースト戦略と多層防御（事例） 3. 重要インフラ業種における クラウドファースト戦略と多層防御（事例） 4. まとめ／Q&A 2
- 3. 1. クラウドセキュリティアライアンスにおける ID管理の取組 3 1-1. クラウドコンピューティングのための セキュリティガイダンス V2.1（2009年12月）とID管理 1-2.クラウドコンピューティングのための セキュリティガイダンス V3.0（2011年11月）とID管理 1-3.クラウドコンピューティングのための セキュリティガイダンス V4.0（2017年7月）とID管理 1-4.SecaaS（Security as a Service）導入ガイダンス カテゴリー1：アイデンティティ／アクセス管理(2012年9月）
- 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 利用者に関しては、仮想サーバを起動するために使用されるサードパーティイメージを、ユー ザーおよびイメージの信頼性の観点で確認する必要がある。 イメージのライフサイクル管理に提供 されるサポートの検討は、あなたの内部ネットワークにインストールされているソフトウェアと同じ原 則をもとにして確認しなければならない。
- 12. 1-2.クラウドコンピューティングのためのセキュリティ ガイダンス V3.0（2011年11月）とID管理(1) クラウドコンピューティングのアーキテクチャフレームワーク ガバナンスとエンタープライズリスクマネジメント 法律問題：契約と電子的証拠開示 コンプライアンスと監査マネジメント 情報管理とデータセキュリティ 相互運用性と移植容易性 従来からのセキュリティ対策、事業継続性、災害復旧 データセンター運用 インシデントレスポンス アプリケーションとセキュリティ 暗号化と鍵管理 アイデンティティ、権限付与、アクセス管理 仮想化 Security as a Service 12 ID管理： オンプレミス型から クラウド型へと企業 システムが拡張する 中で、拡張性の問題 に直面している ↓ クラウドファースト のID管理アーキ テクチャを実装 して、「多層防御」 エコシステムの 中核を担う
- 14. 1-2.クラウドコンピューティングのためのセキュリティ ガイダンス V3.0（2011年11月）とID管理 (3) アイデンティティ、権限付与、アクセス管理(2) クラウドにおけるアイデンティティアーキテクチャ アイデンティティ連携 複数のアイデンティティと属性のソースをベースに、権限付与プロセス で定義したルールに従って、アクセス管理の決定をする。 14 出典：Cloud Security Alliance「Security Guidance for Critical Areas of Focus in Cloud Computing V3.0」 （2011年1月） Exchange Active Directory Azure Active Directory （例）
- 15. 1-2.クラウドコンピューティングのためのセキュリティ ガイダンス V3.0（2011年11月）とID管理 (4) アイデンティティ、権限付与、アクセス管理(3) アイデンティティと属性のプロビジョニングとガバナンス： ＜アイデンティティと属性の例＞ ユーザーアサーション：ユーザ識別子（ペアであるパブリック/プライベートキーのパブリッ クキー） ユーザー名（ユーザー名はアイデンティティの別な属性でなければならない） 資格証明の強度/信頼 位置アサーション；IP アドレス、位置情報、GPS、携帯電話サービス位置情報 組織識別子（識別子－暗号）と組織アサーション デバイスアイデンティティ（識別子－暗号）とデバイスアサーション；必要機能、提示機能、 サンドボックス機能、セキュアコンテナー、デバイスのクリーン度 コードアイデンティティ（識別子－暗号）とコードアサーション トレーニングの記録/コンプライアンス、等 ＊アイデンティティと属性のソースは、権限付与プロセスの設計時に 特定されている必要がある 15
- 17. 1-2.クラウドコンピューティングのためのセキュリティ ガイダンス V3.0（2011年11月）とID管理 (6) アイデンティティ、権限付与、アクセス管理(5) 権限付与（承認）とアクセス管理(2) ＜高いレベルのセキュリティポリシーを低いレベルの技術的アクセス ルールに変換するアプローチ＞ 抽象度の高いレベルのセキュリティ要求事項をモデリングし、別のステークホ ルダが作成するシステムで利用可能なその他の情報ソースを用いるツールが 支援するモデルドリブンのセキュリティプロセス 複雑さを減らすため、技術的なアクセスルールを類似するグループにまとめる 技術的なポリシーをもっと容易に理解できるようにする視覚的試み ＜権限付与プロセスの担い手＞ センター/外部のポリシー強制ポイント/ポリシーサーバ/Policy as a Service クラウドアプリケーションの一部に組込まれる場合 Identity as a Service（IDaaS）を使用する場合 17
- 18. 1-2.クラウドコンピューティングのためのセキュリティ ガイダンス V3.0（2011年11月）とID管理 (7) アイデンティティ、権限付与、アクセス管理(6) アイデンティティと属性提供者とのインタフェースに必要なアーキテクチャ ハブが中心となつてアイデンティティと属性を管理（調整）し、次いでクラウド サービスあるいはクラウドアプリケーションと会話する「ハブ＆スポーク」モデル 複数のソースのアイデンティティと属性を受容するようクラウドサービスそして/ またはアプリケーションが構成される「自由形式」モデル 複数のコンポーネントが分散し、潜在的に他のクラウドサービスを使用する「ハ イブリッド」モデル 18 出典：Cloud Security Alliance「Security Guidance for Critical Areas of Focus in Cloud Computing V3.0」 （2011年1月） 「ハブ＆スポーク」モデル 「自由形式」モデル
- 20. 1-2.クラウドコンピューティングのためのセキュリティ ガイダンス V3.0（2011年11月）とID管理 (9) アイデンティティ、権限付与、アクセス管理(8) アイデンティティに必要なアプリケーション設計 アイデンティティと属性の必要性を最少にしなければならない ユニークなアカウントを生成する場合、システムがエンティティに基づく外部の ユニークな識別子を利用するかどうか、あるいはシステムが自身で独自の識別 子（例．利用者参照番号）を生成する必要があるかどうかを決定する クラウドアプリケーションは、SAML（Security Assertion Markup Language）や Oauth、WS-Federationのような標準の SSO の連携フォーマットを受け入れる 必要がある アイデンティティと属性を利用するアプリケーションを設計する場合、アイデン ティティがあらゆるエンティティを含み、そしてアプリケーションのセキュリティが、 可能な限りあらゆるレイヤ（ネットワークレイヤ、システムレイヤ、アプリケーショ ンレイヤ、プロセスレイヤ、そしてデータレイヤ）を含む全体的なアプローチの一 部であるべきである 20
- 22. 1-3.クラウドコンピューティングのためのセキュリティ ガイダンス V4.0（2017年7月）とID管理(1) クラウドコンピューティングの概念とアーキテクチャ ガバナンスとエンタープライズリスクマネジメント 法律問題、契約と電子的証拠開示 コンプライアンスと監査マネジメント 情報ガバナンス 管理プレーンと事業継続 インフラストラクチャ・セキュリティ 仮想化とコンテナ インシデント・レスポンス アプリケーション・セキュリティ データセキュリティと暗号化 アイデンティティ、権限付与、アクセス管理 Security as a Service 関連技術 22 ＣＳＡジャパンで 日本語翻訳版策 定作業中
- 23. 1-3.クラウドコンピューティングのためのセキュリティ ガイダンス V4.0（2017年7月）とID管理(2) ＜主な変更点＞ DevOps SDN（Software Defined Networks） マイクロサービスとコンテナ 新たな規制ガイダンスと監査と法令順守の継承の役割. CSAツール（例． CCM, CAIQ, STAR）を利用したクラウドリスクの意思決定通知 クラウド管理プレーンのセキュア化 ハイブリッドクラウド向けの一層実践的なガイダンス コンテナとサーバレス向けセキュリティガイダンスの算定と仮想マシンセキュリティ 管理のアップデート 不変の、サーバレスで、新しいクラウドアーキテクチャの利用 越境データ移転、GDPR、NIS指令およびその他の国固有の例（APAC、米州、 EMEA地域）を含む、データ保護ガイダンスのアップデート 23
- 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の導入＞
- 34. 2-1.クラウドを守る「多層防御」のエコシステム 重要インフラのユーザーとクラウド事業者の責任分界点 ⇒「多層防御」（Defense-in-Depth）のエコシステム 34 出典：DoD Defense Information Systems Agency「Department of Defense Cloud Computing Securitｙ Requirements Guide Version 1, Release 2」（2016年3月18日）
- 36. 2-2.重要インフラを支える クラウドファーストのICT戦略：英国事例(2) 英国内閣府「政府クラウド（G-Cloud）戦略」（続き） (https://www.gov.uk/government/publications/government-cloud-strategy） G-Cloudプログラムの共通フェデレーションモデル ＊超早期段階におけるセキュリティ／プライバシー対策の作り込み 36 出典：U.K. Cabinet Office 「Government cloud strategy」（2011年10月27日）
- 37. 2-2.重要インフラを支える クラウドファーストのICT戦略：英国事例(3) 英国内閣府「政府セキュリティ分類」（2014年4月施行） （https://www.gov.uk/government/publications/government-security-classifications） 政府機関が保有する情報資産の取扱いルール：3区分のセキュリティ 分類 「OFFICIAL」 「SECRET」 「TOP SECRET」 37 出典：U.K. Cabinet Office「Government Security Classifications April 2014」（2013年10月18日）
- 38. 2-2.重要インフラを支える クラウドファーストのICT戦略：英国事例(4) 英国デジタルサービス（GDS）「マーケットプレイスのための G-Cloudフレームワーク」（初版：2013年9月12日、最新版： 2017年5月22日） （https://www.gov.uk/guidance/the-g-cloud-framework-on-the-digital-marketplace） 政府機関が利用可能なデジタルマーケットプレイス上のサービス 「G-Cloud」フレームワークを介したクラウドサービス 「Digital Outcomes and Specialists 」フレームワークを介したデジタルアウ トカム、デジタルスペシャリスト、ユーザー調査サービス 「Crown Hosting Data Centres」フレームワークを介した物理的なデータセ ンター空間 「G-Cloud」フレームワーク（最新版はG-Cloud 9） クラウドホスティング クラウドソフトウェア クラウドサポート 38
- 40. ＜参考 1.＞ 英国「G-Cloud」フレームワークのセキュリティに関する 要求事項14原則(1) 40 原則 表題 内容 原則1 転送中のデータ の保護 ネットワーク転送中のユーザーデータは、改ざんや傍受に対 し、適切に保護されるべきである。 原則2 資産の保護とレ ジリエンス ユーザーデータと保存または処理する資産は、物理的な改 ざん、損失、損害または占拠に対して保護されるべきである。 原則3 ユーザー間の分 離 悪意のあるまたは感染したサービス・ユーザーは、他のサー ビスまたはデータに影響が及ばないようにすべきである。 原則4 ガ バ ナ ン ス ・ フ レームワーク サービスプロバイダーは、そのサービスと情報の管理を調整 して方向づける、セキュリティガバナンス・フレームワークを 有するべきである。このフレームワーク外に導入された、い かなる技術的コントロールも、根底から覆されるであろう。 原則5 運 用 セ キ ュ リ ティ 攻撃を妨害・検知・予防するために、サービスを、セキュアに 運用・管理する必要がある。優れた運用セキュリティは、複 雑、官僚的、時間の浪費、高額のプロセスを必要とすべきで はない。
- 41. ＜参考 1.＞ 英国「G-Cloud」フレームワークのセキュリティに関する 要求事項14原則(2) 「G-Cloud」フレームワークのセキュリティに関する要求事項14原則（2） 41 原則 表題 内容 原則６ 従業員のセ キュリティ 信頼するのに高い信頼性が必要なデータやシステムに、 サービスプロバイダーの従業員が、アクセスするところ。適切 なトレーニングによりサポートされた審査により、サービスプ ロバイダーの従業員による偶発的もしくは悪意のある漏えい の可能性を少なくする。 原則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ホットスポットなど、セキュアでないネット ワーク上で傍受される特定のリスクがある。
- 48. 2-3. クラウドファースト時代を支える 多層防御型サイバーセキュリティ：英国事例(3) 通信電子セキュリティグループ（CESG）「Microsoft Office 365セキュリティガイドライン：電子メール」（2015年11月4日） （https://www.gov.uk/government/publications/microsoft-office-365-security- guidance/microsoft-office-365-security-guidance-email） 電子メールの保護（例．保存／転送時の暗号化） トランスポート層セキュリティ（TLS） 電子メールフロー Outlookルーティング Outlookゲートウェイと第三者メールサービス MX (Mail Exchanger) レコード ハイブリッド導入 信頼性と証明書 Microsoftとハイブリッド導入 シングルサインオンとハイブリッド導入 48
- 52. 3-1. 英国医療界：プレシジョン・メディシンの事例(2) 全ての市民のデータが保護されていることを保証する（再掲） 全ての市民が、保健・社会医療専門家との正式な対面診察以外 に、個人データを共有するための選択を表明できるようにする データフローに関する異なる選択を処理することができ、市民が自 分の選択を変えることができるようにする 単独または複数の保健医療提供者と、アプリケーションまたは医 療機器からのデータを共有するか否か、市民が意思決定できるよ うにする いつ、なぜ、自分のデータが直接の医療以外の目的のために利 用されたか。市民がわかるようにする 「NHSデジタルサイバーセキュリティプログラム（CSP）」 「CareCERT (Care Computing Emergency Response Team)」 (https://www.igt.hscic.gov.uk/CyberWhatIs.aspx) ・・・米国のNational Health ISACに該当・・・ 52
- 58. 3-1. 英国医療界：プレシジョン・メディシンの事例(8) 英国保健省「ゲノミクス・イングランド」(4) 情報セキュリティの責任分担 ⇒ 多層防御エコシステムの組織的対策 上級情報リスクオーナー（SIRO: Senor Information Risk Owner） 情報ガバナンス・リード（IG Lead） 情報資産オーナー（IAO: Information Asset Owner） ラインマネージャー（*非常勤スタッフ、外部委託先の管理責任を担う） 全スタッフ など ポリシー集 情報ガバナンス管理フレームワークとポリシー 機密保持とデータ保護ポリシー 情報セキュリティポリシー 情報品質および記録管理ポリシー データアクセスおよび許容される利用ポリシー など 58
- 59. 3-1. 英国医療界：プレシジョン・メディシンの事例(9) 英国保健省「ゲノミクス・イングランド」(5) データ保存・分析システム 政府機関向けパブリック・クラウドサービス上に、仮想デスクトップ 環境をベースとするゲノミクス・イングランド・プラットフォームを構 築・運用 ゲノムデータを クラウドストレ ージに保存 ID／アクセス管理 は、ハイブリッド環境 におけるデータ連携 の要 59 出典：Genomics England「Data types and storage in the 100,000 Genomes Project」 （https://www.genomicsengland.co.uk/the-100000- genomes-project/data/data-types-and-storage/）
- 60. 3-1. 英国医療界：プレシジョン・メディシンの事例(8) 英国保健省「ゲノミクス・イングランド」(6) （例）「UKCloud」のクラウドセキュリティ管理策 （https://cloudsecurityalliance.org/star-registrant/ukcloud-ltd/） ＊CSAのCCM／CAIQ／CSA STAR認証関連公開情報を共通の評価指標 として活用すると、クラウド事業者間の相対的な比較が可能 60 出典：Cloud Security Alliance 「STAR Registrant UKCloud Ltd」 （2016年10月28日）