【WP for IT Pros】Windows Phone のセキュリティモデル 3 ~ データの保護

前回までの投稿は以下の通りです。 【WP for IT Pros】Windows Phone のセキュリティモデルについて~「チャンバー」という考え方(1) 【WP for IT Pros】Windows Phone のセキュリティモデルについて~「チャンバー」という考え方(2) 今回は Windows Phone のデータ保護について解説します。 社内や社外に与える影響の大きさに関わらず、社内データの保護や、データの整合性を維持することは企業にとって重要です。Windows Phone には、社内データを外部に流出するリスクを最小限に抑えるための手段が用意されています。 Windows Phone は「多層的な(multi-layered)縦深防御(Defense in Depth)」というアプローチを用いて、データの保護を実現しています。縦深防御とは複数の防御ラインを用意することで目的のデータに到達することを困難にすることで、仮に1つの防御ラインが突破されても他に用意された防御ラインによってデータは保護され続けます。 さらに、Windows Phone のあらかじめ決められている仕様により、ハードウェアベンダーを問わず全ての Windows Phone が同じ管理機構、セキュリティ制御機構を持っており、組織内の一貫したモバイルデバイス管理を可能にしています。 デバイス アクセス ポリシー 最初の防御ラインとしてロックスクリーンが用意されています。スクリーンロックを解除するには、PIN または複雑なパスワードを使用しなければなりません。スクリーンロックを解除するためのセキュリティコードは、EAS(Exchange ActiveSync)パスワードポリシーと関連付けることができます。EAS パスワードポリシーが構成されると、Exchange Server に接続されている全ての Windows Phone に、このポリシーが強制的に適用されます。 現在、世界中の多くの企業が Exchange Server を採用しています。マイクロソフトはブロードキャスト的にデバイスにリーチできるこのインフラストラクチャを、デバイス管理を簡素化する方法として使用することにしました。EAS は長年使われてきたテクノロジーであり、堅牢なコミュニケーションプロトコルです。Windows Phone 7.5 には EAS 14.1 が実装されており、email、カレンダー、タスクそしてコンタクト情報の同期がサポートされています。 *…

1

【WP for IT Pros】Windows Phone のセキュリティモデル 2 ~「チャンバー」という考え方(2)

前回は「チャンバー」の概念についてお話ししました。 【WP for IT Pros】Windows Phone のセキュリティモデルについて~「チャンバー」という考え方(1) 今回は、その補足的な内容となるのですが、「機能ベースの権限モデル」と「サンドボックス」について書きます。 ■ 機能(Capabilities)ベースの権限モデル 「機能」とは別の言い方をすれば「リソース」です。Windows Phone にはさまざまな機能が実装されており、「位置情報」「カメラ」「マイク」「ネットワーク」「センサー」などが「機能」に該当します。これらの機能は、Windows Phone の使い方と密接に関連していることは言うまでもありませんが、機能こそが「ユーザープライバシー」「セキュリティ」「コスト」「ビジネスに関する考慮事項念」などに影響を与えることになります。 既に述べたように、LPC(Least Privileged Chamber)には規定で必要最小限のアクセス権限が与えられています。しかし、だからといって LPC 内のアプリケーションがそれ以上の機能を使用できないわけではありません。例えば LPC 内のアプリケーションが「カメラ」機能を使用する必要がある場合には、アプリケーションのインストール中に「カメラ」へのアクセスがユーザーに打診されます。ユーザーがそれを承認すれば、アプリケーションはカメラ機能を使用することができるようになります。ただし、こうした権限の昇格はアプリケーションの実行中に与えられることは無く、かならずアプリケーションを使い始める前に承認される必要があります。 このようにして、LPC はダイナミックに「機能」によってによって権限が拡張されます。これを「機能ベースの権限モデル」と呼びます。 機能ベースの権限モデルには、以下のような利点が挙げられます。 – アタック面の最小化 それぞれのアプリケーションは、その動作に必要最小限の「機能」のみを使用する。攻撃の対象はそれらの機能に付随することになるが、逆に言えばその範囲に留まるということでもある。 – ユーザーの承諾と制御 それぞれのアプリケーションが利用者に対して、どのような機能を使用するのかを提示する義務を負う。規定では、以下に示す場所とタイミングで使用する機能を提示しなければならない。 Windows Phone Marketplace 内のアプリケーション詳細説明ページ アプリケーションの購入画面 アプリケーションを最初に使用するとき アプリケーションの開発者は、Windows Phone の開発ツールを使用して、機能リストを作成する必要があります。機能リストはアプリケーションパッケージの WMAppManifest.xml ファイルに格納されます。 ■ サンドボックス Windows phone の全てのアプリケーションが、それぞれの分離したチャンバーの中で事前に定義された機能とともに動作することは既に述べたとおりです。 このとき、必要最小限の権限が全てのアプリケーションに与えられますが、その中には「分離ストレージ」へのアクセス権も含まれています。アプリケーション間には、クラウド等の外部デバイスを除き、いかなる通信チャネルも存在していません。アプリケーションは互いに完全に分離されており、当然のことながら互いのメモリやデータにアクセスすることもきません。これにはキーボードのキャッシュも含まれています。 加えて、Windows Phone はバックグラウンドで動作することも許されていません。これにより、意図的に隠されたアプリケーションや、いわゆるスパイウェアから利用者のデータを守っています。利用者が別のアプリケーションに切り替えたときには、これまで使用していたアプリケーションは休止状態となり、それまでの動作状態が保存されます。こうしたアプローチにより、アプリケーションがリソースを食いつぶしたり、裏で勝手にインターネットにアクセスするといったことを抑止しているのです。 本来参照する権限を持たないユーザーに対して社内情報を流出してしまうなど、スマートフォンにありがちな一般的なリスクを軽減するには、堅牢なセキュリティで守られたデバイス上にアプリケーションを展開する必要があります。 Windows Phone はデバイス自身がこのようなセキュリティで守られている他、Exchange…


【PowerShell】WEB ページをアーカイブする

ちょっと必要に迫られて調べただけなので、中途半端な情報ですみません。役に立つ方がいらっしゃるかもしれないので投稿しておきます。 WEB サイトの移行や廃棄等で、既存のページのバックアップを取っておきたい場合があります。それも、大量にあるので出来る限り自動化したいという。 方法はいくつかあるのですが、代表的な方法として2つ考えられます。 ※ここでは再現性の高い MHT 形式で保存するものとします。 1. CDO.Message を使用する いにしえの方法で、こなれた感じではありますが、正直なところ出力結果に難ありです。 例えば、Tech Fielders サイトで公開されている、Windows Intune 利用時に知っておくべき Proxy Server 環境設定 | Tech Fielders コラム(三井情報株式会社 後藤 諭史 さん)を保存してみます。 $url = "http://www.microsoft.com/japan/powerpro/TF/column/sg_01_1.mspx" $filename = "c:\tmp\tf\sg_01_1.mht" $cdo = New-Object -ComObject "CDO.Message" $n = $cdo.CreateMHTMLBody( $url, 0, "", "") $objStm = $cdo.GetStream() $objStm.SaveToFile( $filename,  2) 実行結果は以下の通りです。読めなくはないですが、レイアウト的に微妙な感じですよねぇ。 ちなみに、CreateMHTMLBody メソッドの第二パラメタ「0」は、指定したURLの全てのコンテンツをダウンロードすることを示しています。 (参考)CdoMHTMLFlags Enum…

3

【WP for IT Pros】Windows Phone のセキュリティモデル 1 ~「チャンバー」という考え方(1)

Windows Phone のセキュリティモデルについて断片ばかりで系統的に語ったことが無かったので、あらためて。 参考:Download: Windows Phone 7.5 IT Papers – Microsoft Download Center – Download Details 以下の図は、Windows Phone のセキュリティモデルを模式的に表したものです。 Windows Phone のセキュリティモデルは「分離の原則」と「最小限の権限」という思想のもとに設計されており、「チャンバー」と呼ばれるコンセプトに沿って実装されています。 ここで言う「チャンバー」とは、心室や心房などのように仕切られた部屋を意味しています。Windows Phone 上で動作するアプリケーションやドライバーは、必ずいずれかのチャンバーに隔離され、チャンバーごとに定義されたアクセス権限のみを行使することができます。これにより Windows Phone で動作するアプリケーションの独立性と必要最小限のパーミッションによる動作が保障されています。 チャンバーはセキュリティポリシーの定義によって以下の4つのタイプに分けられています。 TCB(Trusted Computing Base)チャンバー 最も高度な権限を持ったチャンバー。Windows Phone 内のリソースの大部分に無制限にアクセスすることができる。TCB チャンバーはポリシーを変更したり、セキュリティモデルを強制することができる。カーネルとカーネルモードドライバーは TCB チャンバー内で動作する。TCBチャンバー内で動作するアプリケーションを最小限に抑えることが Windows Phone へのアタック面を最小限に減らすことになる重要な要素である。マイクロソフトだけがTCBチャンバーにアプリケーションを追加できる。 ERC(Elevated Rights Chamber) セキュリティポリシーを除く全てのリソースにアクセス可能なチャンバー。ERC は、他の Windows Phone アプリが使用する機能を提供するサービスやユーザーモードドライバを対象にしている。マイクロソフトだけが ERC にソフトウェアを追加することができる。 SRC(Standard Rights Chamber) SRCはプリインストールアプリケーションに与えられる既定のチャンバーである。デバイス全体に影響するサービスを提供するアプリを除き、すべてのプリインストールアプリケーションはSRCで動作する。マイクロソフトの…


生涯エバンジェリストでありつづけることは難しいことです

マイクロソフトに「テクノロジー エバンジェリスト」として入社する人間は、方向性に差はあるものの、それぞれに IT への強い思い入れを持っています。 技術を愛していることは言わずもがな、それによって IT 業界を変えられると真剣に信じています。 しかし大きな夢はプレッシャーでもあります。限界を感じることもあり、夢半ばで離脱される方も少なくありません。 今年入社5年となる私も、暗闇の中でいつ限界が来るのだろうかと考えることがあります。私だけではないはずです。周囲の全員がそうでしょう。 祓いきれないプレッシャーを抱える我々の心の支えは、間違いなく偉大なる先輩方です。 既にご存知の方も多いと思いますが、2012年1月20日、エバンジェリストである 川西 裕幸 さんがお亡くなりになりました。 私の UX & Client プラットフォーム推進部への移動によって、2011年7月、より近しい存在となった 川西 さんは、偉大なる大先輩の1人でした。 正論を吐き続けるだけでは、長い年月をエバンジェリストであり続け、かつ社内外からの高い評価を維持し続けることはできません。ニューテクノロジーに詳しいだけでは言葉が軽くなります。 言葉の重みは歴史の重みでもあります。 川西さんの言葉や文章には、間違いなく重みがありました。 テクノロジーの歴史を未来に向けて紡ぐことができる、稀有なエバンジェリストでした。 私たちエバンジェリストは、まだまだ川西さんから学ぶべきことが多くありました。 それだけに川西さんの訃報が残念でなりません。 いまはただ、川西さんのご冥福をお祈りします。 川西 裕幸のブログ http://blogs.msdn.com/b/hiroyuk/ Facebook https://www.facebook.com/profile.php?id=721589565&ref=tn_tnmn#!/profile.php?id=100002542766076


【IDM】AD FS で既存のクレームルールセットをバックアップするには

前回以下の投稿をしました。 【IDM】AD FS で Event ID 323、364 が発生して認可されない場合の対処 この投稿に関連し、既存のクレームルールセットをバックアップする方法についても紹介しておきます。クレームルールは大切なリソースですから、変更の前には必ずバックアップするようにしましょう。 AD FS には PowerShell 用コマンドレットが大量に用意されており、それらを使えばバックアップなんて簡単です。 AD FS 2.0 Cmdlets in Windows PowerShell クレームルールセットを取得できるのは、以下の2つです。 Get-ADFSClaimsProviderTrust :要求プロバイダー信頼に関する情報の取得 Get-ADFSRelyingPartyTrust :証明書利用者信頼(RP)に関する情報の取得 いずれのコマンドレットも、出力のフォーマットは同様です。今回は、Get-ADFSClaimsProviderTrust を使用してみます。 PowerShell コンソールを開き、 以下のコマンドレットで AD FS スナップインを読み込んでください。 PS C:\>Add-PSSnapin Microsoft.Adfs.Powershell 要求プロバイダー名が "Active Directory" であれば、以下のようにして要求プロバイダーの情報を取得することができます。 PS C:\> Get-ADFSClaimsProviderTrust -Name "Active Directory" 出力結果の中に AcceptanceTransformRules というプロパティが用意されていますが、これがクレームルールセットです。 そこで、以下のように入力すると、以下のように、クレームルールセットのみを取得することができます。 PS C:\> $cp =…

1

【IDM】AD FS で Event ID 323、364 が発生して認可されない場合の対処

みなさん、AD FS 使ってますか~? とかるーいノリで…。 たったいま、ハマった現象について覚書程度に記しておきます。 AD FSをインストールすると、規定の要求プロバイダーとして Active Directory が登録されます。 でもって、この要求プロバイダー"Active Directory"には、既定のクレームルールセットが登録されています。 この規定のクレームルールを削除してしまうと、認証方式や認証のタイムスタンプ等をRP(Relying Party)側に伝えることができなくなり、RP 側の STS からセキュリティトークン発行を拒否されてしまうことがあります(RP 側 STS の実装によります)。 拒否されると、イベントログには以下のようなイベントが出力されます。 フェデレーション サービスは、発信者 ” から証明書利用者 ‘https://tfazureforitpro.accesscontrol.windows.net/’ へのサブジェクト ‘Administrator’ の代理としてのトークンの発行を承認できませんでした。 発信者 ID については、同じインスタンス ID を持つイベント 501 を参照してください。 OnBehalfOf ID (存在する場合) については、同じインスタンス ID を持つイベント 502 を参照してください。 インスタンス ID: d3c3c678-6bce-4fb5-90ee-f86810c4c53c 例外の詳細: Microsoft.IdentityServer.Service.IssuancePipeline.OnBehalfOfAuthorizationException: MSIS5009: 証明書利用者信頼 https://tfazureforitpro.accesscontrol.windows.net/ の発信者 ID および委任…


【WP for IT Pros】AD FS 接続テストツール(ADFSClient)を公開しました

非常にニッチな Windows Phone アプリを公開しました。 その名も、AD FS 接続テストツール です。 社内の AD FS から SAML トークンが正しく受け取れるかどうかを検証するためのツールです。 まだマーケットプレースの検索にはヒットしないようですが、以下からダウンロードすることができます。 http://www.windowsphone.com/ja-JP/apps/6396423a-d26e-4ef7-a03e-9e695f87d52b 画面は以下の1画面だけ(笑)。「ログオン」をタップして正常に認証/認可されると、右のような画面が表示されます。これだけです。    こんなアプリも公開可能なので、ITPROの方にも是非チャレンジしていただきたいですねl このアプリのソースコードは以下で公開しています。是非もっと便利にアレンジして使ってください! 2011/11/28 セミナー資料 Windows Phone アプリケーションに認証機能を実装する

1

【PowerShell】「ブロックを解除」するためのメソッドを追加してみる

前回の投稿では、CodeProject で公開されているライブラリを使用して、一括でブロックを解除する方法について紹介しました。 【PowerShell】一括で「ブロックを解除」する ~ Windows PowerShell 編 その1 頻繁に使用するかどうかははなはだ疑問なのですが、ついでなので「ブロックを解除」するためのメソッドを追加しちゃいましょう。 メソッドを追加するとはどういうことか?例えば、以下のような感じです。 PS C:\> $File = Get-Item .\IdentityModel.WP7.dll PS C:\> $File.DeleteAlternateDataStream 標準では Get-Item で作成した $File には、DeleteAlternateDataStream というメソッドは用意されていません。それを作ってしまおうということです。 なんか、とてつもないことを言っているように感じるかもしれませんが、PowerShell では、既存の Types.ps1xml ファイルを編集したり、新しい Types.ps1xml ファイルを作成することで、メソッドやプロパティを追加することができます。もちろん、内部の処理はスクリプトで書くことができるので、Visual Studio を使って云々..なんて必要もありません。 参考サイトはたくさんありますが、いちおうスタンダードなものは以下でしょうかね。 about_Types.ps1xml では早速着手してみましょう。 1.メソッドを追加するクラスを特定する はじめに、どのクラスにメソッドやプロパティを追加するかを決めておく必要があります。 今回は、$File = Get-Item .\IdentityModel.WP7.dll で取得した $File に対してメソッド等を追加しようとしています。 では、$File のクラスはどうやってを調べるのかといえば、以下のようにして調べることができます。 PS C:\> $File.GetType().FullName System.IO.FileInfo もし、Get-Item で取得したオブジェクトがレジストリキーであれば、クラスは以下のように Microsoft.Win32.RegistryKey となります。…


【PowerShell】一括で「ブロックを解除」する ~ Windows PowerShell 編 その1

先の投稿で、一括で「ブロックを解除する」方法についてご紹介しました。 【Management】一括で「ブロックを解除」する ~ streams コマンド編 ただ、この方法だとファイルの代替データストリームを全て削除してしまうので、ちょっと感じ悪いというか…なんか他に影響が出ないかすごく心配だったりします。IT Pro 的には。 ※ ちなみに、ファイルのプロパティから「ブロックを解除」すれば、ZoneID のみを削除することができます。ただし、ファイル単位に操作するので超面倒なのですね。 代替データストリームは、Dir /r コマンドで確認することができます。例えば、以下の場合には、4つの代替データストリームが存在していることがわかります。 C:\tmp>dir /r IdentityModel.WP7.dll ドライブ C のボリューム ラベルがありません。 ボリューム シリアル番号は 6E7E-0B00 です C:\tmp のディレクトリ 24/01/12  20:08            44,032 IdentityModel.WP7.dll                                 7 IdentityModel.WP7.dll:ads1:$DATA                                 7 IdentityModel.WP7.dll:ads2:$DATA                                 7 IdentityModel.WP7.dll:ads3:$DATA                                26 IdentityModel.WP7.dll:Zone.Identifier:$DATA                1 個のファイル              44,032 バイト                0 個のディレクトリ  16,348,221,440 バイトの空き領域 dir /r…