NPO日本ネットワークセキュリティ協会Japan Network Security Association JNSA 2014年度活動報告会「 2014年度アイデンティティ管理WG成果報告」富士榮 尚寛(伊藤忠テクノリューションズ) 2015年 6月 9日(火)ベルサール神田ＷＧ活動報告内容JNSA 1． 2 0 1 4年度の活動内容2．IDの融合と分離3．特権ID管理4.今年度の活動テーマ
Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会J N O Y 2 0 1 4年度活動内容について２０１３年度は以下のテーマで議論をいたしました。 1． IDの融合と分離2．特権ID管理3.ロール管理IDとプライバシー（勉強会） 4. 5．普及活動および資格制度検討
また、各種セミナー協力、他団体連携を行いました。 1． ID & IT Management Conference 2014 (9/17,9/19)協力• OpenID EIWGについては一旦協力終了・ID連携トラストフレームワークについては動きがあれば協力する(今後) • CSA-J ( Cloud Security Alliance Japan )の協力を模索中Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会JNSA
IDの融合と分離
●個人はコンテキストに応じた各種アイデンティティを保有しているが、全体として一個人●コンテキストに応じて使い分けるのは不便だが、別コンテキストのアイデンティティとは分離したい場合がある✓パブリック(範囲限定を含む)とプライベート✓ビジネス／ソーシャルとパーソナル●用語の定義✓結合:異種のアイデンティティを同一個人として結び付ける✓融合:異種のアイデンティティを一つにまとめる✓分離:異種のアイデンティティを結合も融合もさせないCopyright (c) 2000-2015   NPO日本ネットワークセキュリティ協会検討テーマJNSA ●各種の個人アイデンティティの結合・融合・分離にかかわるメリット／デメリットの明確化、課題の整理と解決方法の考案✓職業人✓公民(国民、自治体民) ✓コミュニティ人✓消費者●各種の個人アイデンティティを洗い出し、以下を整理✓個人アイデンティティの特徴✓個人属性の性質✓個人アイデンティティの位置付け･関係✓個人アイデンティティの結合・融合・分離にかかわるメリット／デメリット、課題● 2015年度は、2014年度の検討内容の精査・深堀、および課題の解決方法を検討する予定Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
検討内容、スケジュール
JNSV
各種個人アイデンティティの洗い出し(1/2) JNSA

各種個人属性の性質(1/6)

各種個人属性の性質(3/6)

Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会各種個人属性の性質(5/6)
Copyright (c) 2000-2015   NPO日本ネットワークセキュリティ協会各種個人アイデンティティの位置付け・関係 JNSA
Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
個人アイデンティティの結合・融合に
かかわるメリット／デメリットの洗い出し（2）

Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
個人アイデンティティの結合・融合・分離にJNSA
かかわる課題の洗い出し(2)

JMSY •個人アイデンティティの結合・融合・分離にかかわる課題整理の精査・深堀–アクセス制御や個人情報保護の観点–維持管理の観点–活用の観点(パーソナライズ、マーケティング、ビッグデータ等) •上記課題の解決方法を検討•考案(〜2015年度末を目標に) Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会JNSA 3.特権ID管理
特権IDの現状の深掘りと管理疾✓特権ID利用の現状に対する管理策ケラサド環境における特種D管理✓ IaaS, PaaS等各種サービス形態における特権ID管理26 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会特権ID管理まとめ方全体マップ
Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
特権ID管理のあるべき論は、昨年度検討してきた。現状のままの運用していた場合の問題点についても整理を行った。今年度は、現状の深堀として・おせてことでしょうているのか・現実的な客としどころ→管理館を検討し、できることから始められる管理策を整理する。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
「特権ID」こんな使い方してませんか？
特権IDは、与えられた権限が大きいため（強いため）便利に使えます。特に製品の出荷状態から設定されている特権IDは、初期設定作業のためにすべての権限を付与されている場合もあります。そして、初期設定が終わってからもそのまま使い続けてしまいがちです。製品にビルドインされた特権IDを構築作業時にベンダーが設定したパスワードのまま、複数名のIT担当者が共有で常時利用している。ついつい、このような使い方をしてしまっていませんか？ . . . . . . . .製品にビルトインされているアカウントを使っている。構築作業時にベンダーが設定したパスワードがそのままになっている。不特定多数のユーザが使っている。何でもできる便利なアカウントとして常用している。連携用として複数のシステムで共有している。長期間同じパスワードで利用してる。同じパスワードを複数のシステムで使いまわしている。類推しやすいパスワードを設定している。
製品にビルトインされているアカウント(特権ID)を使っているパスワードを出荷状境の手長だったり理由/背景：あらたに設定することが面倒！設定しても、特権IDの利用頻度が低いから、忘れそうなのでそのまま製品上設定できない脅威：製品にビルトインされている特権を持ったIDは、初期パスワードを含めインターネット上に情報として公開されてしまっているケースがほとんどです。IDと初期パスワードが一般に知られてしまっている状況ですので、パスワードの秘匿だけが保護の手段となります。対策：パスワードは初期値から必ず変更（空白の場合は設定）することを強くお勧めします。また、システム上可能な場合は無効化することも有効です。パスワードの持ち主を決めて、変更後のパスワードがわからなくならないようにしましょう。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
特権IDの現状と対策
(2)
構築作業時にベンダーが設定したパスワードがそのままになっている。理由/背景：変更することが面倒だ、変更することを忘れていた！いざというときにベンダーに調査を依頼したいのでそのままにしておきたい。パスワードの管理はベンダーに任せている。 ID/パスワードを払い出す仕組みがない。脅威：パスワードを知っているベンダー側のエンジニアが誰かを把握することが困難です。そのためパスワードがどのように伝播するかコントロールできなくなります。別の作業時に勝手にアクセスされても把握しにくい状況に陥ります。対策：作業毎にIDを払い出し、作業後はベンダーに払い出したIDを無効/削除する、もしくはパスワードを変更するなどを行い、意図しないところでアクセスされないようにしましょう。
不特定多数のユーザが使っている。理由/背景：管理者個別にIDを発行することが面倒だ！特権を持ったIDを多く発行することに抵抗がある！脅威： IDを共有してしまうと、実際に誰が利用したか把握ができなくなります。万が一不正アクセスがあった場合に利用者の特定が困難です。対策：一般ユーザとしてログインしたあと、特権を付与する機能（sudoやrunas）を活用しましょう。 →不特定多数って何人？貸し出しの管理台帳で管理。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
特権IDの現状と対策
(4)
何でもできる便利なアカウントとして常用している。理由/背景：オペレーションごとにIDを使い分けることが面倒だ！アプリケーション・プログラムも特権IDアカウントを利用しているため、あまり意識をしていない。 IDを分けるにしても、アプリケーションごとにどういった権限を与えればよいのかわからない。背成:何のためにそのIDでアクセスしてきたのかを特定することが困難です。アプリケーション・プログラムがアクセスするIDと同様のIDで管理者がアクセスをした場合に、アクセスの要因をトレースすることが困難です。オペレーション上不必要な権限を持つIDの利用による人的ミスによる障害を誘発する可能性がありまti対策：特権を持つIDを付与するユーザは必要最低限としましょう。また、複数名でのIDの使いまわしはやめましよう。予め想定できるオペレーション権限を策定し、適切な管理者に対してのみ最低限の権限を付与するようにしましょう。 Copyright (c) 2000-2015   NPO日本ネットワークセキュリティ協会

連携用として複数のシステムで共有している。
理由/背景：他システム側が、処理に必要な権限が何かを把握しておらず、特権IDでとりあえず何とかしたい連携用IDに求められる権限がわかっていたとしても、専用のIDを一々準備できない連携用のIDの利用ルールを事前に定めておらず、それぞれ勝手にパスワードまでプログラムに書き込んでしまった！容威: IDとパスワードが連携対象のシステム側に渡るため、そこからパスワードがもれる可能性があります複数のシステムで共有しているため、パスワードの変更に対応できない使い方をするシステムがひとつでもあると、パスワードの変更そのものが困難になり、漏えいのリスクが高まります。対策:パスワードを使う場合は定期変更が可能な実装をする、あるいは、証明書認証を使い証明書の更新プ口セスを決めておくなど連携用IDの利用ルールを事前に決めておきましょう。パスワードを保管する場合は、暗号化やファイルへのアクセス制御などを行うようにしましょう。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
特権IDの現状と対策
(6)
長期間同じパスワードで利用してる理由/背景：一度設定したパスワードを変更すると周知が面倒変更した際のシステムへの影響が不明なため、変更できない。容威:異動や退職により、管理者の任が解かれた人がアクセスできる手段を知っていることになります。トラブルによる退職者の逆恨みによる不正アクセスの事件などが実際に起きています。対策：パスワード自体を解読される可能性を減らすため、または解読されたり、知られてしまったため進入を許すなどの被害を最小限に抑えるという点で、パスワードを利用後に変更（使い捨て）することが有効です。連続したアクセス試行に回数制限を設定するなどの方策も有効です。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
複数のシステムの特権IDに同じパスワードを設定している。理由/背景：それぞれのシステムで個別に特権IDのパスワードを設定すると管理が面倒！脅威： ーつのシステムの特権IDのパスワードが漏れてしまうと、複数のシステムの特権が奪われることになります。対策：各システムで個別のパスワードを設定しましょう。被害を最小限に食い止めることができます。パスワードの一部にホスト名の頭文字を付けるなど、使いまわしを防止しながらも管理しやすい生成ルールを考える方法などがあります。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
特権IDの現状と対策
(8)
特権IDに簡単な(類推しやすい脆弱な)パスワードを設定している理由/背景：特権IDに複雑なパスワードを設定すると忘れてしまいそう！システムの仕様でパスワードに設定可能な文字種や文字数の制限がある。脅威：インターネット上には、パスワード解析のためのツールや辞書が出回っており、脆弱なパスワードではすぐに解読されてしまう可能性が高く、不正アクセスを防ぐ効果が下がります。対策：類推しにくいパスワードを設定しましよう（SplashData社"Worst Passwords" List等にランクインしているパスワードは設定しない）。複雑さを維持しながら管理しやすいパスワード生成方法などを利用して、パスワードを設定しましょう。システム仕様上での制限がある場合は、ネットワークや物理的(サーバールームへの入退出)な制限を組み合わせて管理しましょう。 【組織プロファイル】 IT部門メンバー数: 10名(派遣社員6名)システム数(サーバー数): 100 【現状】複数のシステムに対し、製品にビルドインされた特権IDを構築作業時にベンダーが設定したシステム共通パスワードのまま、複数名のIT担当者が共有で常時利用している。
【このままでは！】
ビルドインされた特権IDは、普段の運用管理のオペレーションに必要な権限に対して、必要以上に権限を持っていることが多いです。そのため、常時利用が故の人的ミスによる障害を誘発する恐れがあります。ベンダーが設定したままのパスワード、また特権IDの共有は、社内にも社外にも複数名システムヘアクセスできる人が存在することになり、万が一の不正アクセスされた場合に、特権ID利用者の把握ができなくなります。 【対策】システムそれぞれのビルドインされた特権IDに対して、ベンダーが設定したパスワードから個別の複雑性の高いパスワードを設定しましょう。システムの仕様によっては、ビルドインされた特権IDを無効にできるので必要以外のときは無効化にしておきましよう。複数人のシステム管理者で運用を行う場合は、個別にユーザアカウントを必要最小限の権限付与で作成しましょう。 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
クラウド環境は従来と何が異なるのか
オンプレミス環境との違い. . IaaS/PaaS/SaaSの各レイヤがあり、実現モデルが多岐にわたるサービスの利用者と提供者（開発者も含む）がおり、登場人物が多数いるマルチテナントが前提
サーバ仮想化からさらなる発展
•サーバ仮想化ではハイパーバイザ上での管理が主流となる｡ (例:クラウド上のリソースをセルフポータルで管理など。） •コンテナ型対応はユーザ空間が複数なのでリソースを制限し、複数コンテナの管理が求められる。 (例:マルチテナント型のアプリを提供する場合、そのアプリに必要なプロセスだけを含む複数コンテナを起動するなど。)
この図にコンテナ系などの新しい技術の考え方が加味されたらどのように考えられるか出典:NISTバブリッククラウドコンピューティングのセキュリティとプライバシーに関するガイドライン独立行政法人情報処理推進機構訳40 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
クラウドになり、対応が難しくなった所有と利用の混在   → 分離が必要.ハイブリッドクラウド環境への対応(例)自社IaaSを外部IaaSに切り替え.契約や運用面の変化. .サービス利用者と提供者（開発者も含む）の役割法人をまたいだ管理者
技術面の変化
. . .各レイヤ（IaaS/PaaS/SaaS）での管理の必要性縦方向と横方向コンテナ系などの新しい考え方Copyright (c) 2000-2015   NPO日本ネットワークセキュリティ協会
SaaSアプリを中心とした特権ID管理. .払い出された仮想環境の運用テナント単位のID管理• SaaSアプリ利用者. SaaSアプリ開発者SaaSアプリ運用／仮想環境運用者. PaaS/IaaSを中心としたクラウド基盤の特権ID管理払い出すための仮想環境の運用. . VMやハイパーバイザでのID管理.コンテナでのID管理42 Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会クラウド環境における特権ID管理（イメージ）
Copyright (c) 2000-2015   NPO日本ネットワークセキュリティ協会
SaaS/PaaS/IaaS/・・・と多層化し複雑化するクラウド環境において、サービス（リソース）を提供する側と提供される側の二面性を持つた主体に対する特権の付与を個々のシステムでそれぞれ管理するには限界がある。提言: ID連携（ID Federation）により解決できるのでは！ RP（リソース側）：リソースに対して権限の識別子IdP（運用側）：認証後に紐付けIdP
Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会今年度のテーマ(案) JNSA 1. 「クラウド環境におけるアイデンティティ管理」書籍改定2.アイデンティティとプライバシー勉強会（有識者との懇談） 3.エンタープライズロール管理改訂(継続) 4. IDの融合と分離の課題検討(継続) 5. ID管理チェックリスト作成(新規) 6.情報発信活動(資格制度、HP作成)(新規) (その他) •WG設立10周年記念パーティ一企画＊現在、新規メンバー募集中！　６／１２（金）１７時まで！詳細はＪＮＳＡ事務局まで！ Copyright (c) 2000-2015    NPO日本ネットワークセキュリティ協会
計24名（順不同） NPO日本ネットワークセキュリティ協会書籍の紹介書籍名： ＜改訂新版＞クラウド環境におけるアイデンティティ管理ガイドライン出版社：インプレスR&D NextPublishing形態：電子書籍、Ondemand Print(POD)販売： AmazonインプレスR&D libura PRO http://www.amazon.co.jp/dp/4844395866