• 【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 ファイルに格納されます。

    image

    ■ サンドボックス

    Windows phone の全てのアプリケーションが、それぞれの分離したチャンバーの中で事前に定義された機能とともに動作することは既に述べたとおりです。

    このとき、必要最小限の権限が全てのアプリケーションに与えられますが、その中には「分離ストレージ」へのアクセス権も含まれています。アプリケーション間には、クラウド等の外部デバイスを除き、いかなる通信チャネルも存在していません。アプリケーションは互いに完全に分離されており、当然のことながら互いのメモリやデータにアクセスすることもきません。これにはキーボードのキャッシュも含まれています。

    image

    加えて、Windows Phone はバックグラウンドで動作することも許されていません。これにより、意図的に隠されたアプリケーションや、いわゆるスパイウェアから利用者のデータを守っています。利用者が別のアプリケーションに切り替えたときには、これまで使用していたアプリケーションは休止状態となり、それまでの動作状態が保存されます。こうしたアプローチにより、アプリケーションがリソースを食いつぶしたり、裏で勝手にインターネットにアクセスするといったことを抑止しているのです。

    本来参照する権限を持たないユーザーに対して社内情報を流出してしまうなど、スマートフォンにありがちな一般的なリスクを軽減するには、堅牢なセキュリティで守られたデバイス上にアプリケーションを展開する必要があります。

    Windows Phone はデバイス自身がこのようなセキュリティで守られている他、Exchange Active Sync(EAS)によりセキュリティポリシーの集中管理が行えるようになります。EAS については別の記事で解説します。

    以下につづく

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

  • 【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)

    実行結果は以下の通りです。読めなくはないですが、レイアウト的に微妙な感じですよねぇ。

    image

    ちなみに、CreateMHTMLBody メソッドの第二パラメタ「0」は、指定したURLの全てのコンテンツをダウンロードすることを示しています。

    (参考)CdoMHTMLFlags Enum

    また、SaveToFile に指定している 2 は $filename が存在している場合に上書きすることを示しています。1 を指定すると、同じファイルが存在する場合にエラーとなります。

    2. IE の ExecWB を使用する

    この方法は、IE で「ページを名前を付けて保存する」をスクリプトから実行するものです。IE から GUI を操作して保存した場合とまったく同じ結果を得ることができるため、結果の品質は申し分ありません。

    ただ、問題がちょっとだけあります。それは、「名前を付けて保存」を自動化することができないということです。

    以下のスクリプトの最終行に書かれている、ExecWB(4,0,$null,[ref]$null) は IE の「名前を付けて保存」ダイアログを呼び出すためのメソッドです。「4」が「名前を付けて保存」を意味しています。第二パラメタには「0」を指定していますが、「2」を指定するとプロンプトを表示しないで実行ができるはずなのです...が、どうもうまくいかない...ということで、だったらダイアログ操作を自動的にやってしまうことにしました。

    $url = "http://www.microsoft.com/japan/powerpro/TF/column/sg_01_1.mspx"
    $code = '$WShell = New-Object -comobject WScript.Shell; '
    $code = $code + '$WShell.AppActivate(''Web ページの保存'', $true); '
    $code = $code + '$WShell.SendKeys(''%T'') ; '
    $code = $code + '$WShell.SendKeys(''{DOWN}'') ; '
    $code = $code + '$WShell.SendKeys(''{DOWN}'') ; '
    $code = $code + '$WShell.SendKeys(''{ENTER}'') ; '
    $code = $code + '$WShell.SendKeys(''%N'') ; '
    $code = $code + '$WShell.SendKeys(''{HOME}'') ; '
    $code = $code + '$WShell.SendKeys(''C:\TMP\TF\'') ; '
    $code = $code + '$WShell.SendKeys(''%S'')'
    $ie = New-Object -ComObject InternetExplorer.Application
    $ie.Navigate( $url )
    while ($ie.ReadyState -ne 4) { Start-Sleep -Milliseconds 100}
    Start-Process powershell.exe -argument ('-version 2.0 -noprofile -windowstyle hidden -command "{0}"' -f $code)
    $ie.ExecWB(4,0,$null,[ref]$null)

    コードをご覧いただいてもわかるように、ちょっと特殊なことというか...古臭いことをしています。

    Windows Script 時代からスクリプトを使っていた方ならばご存じの、SendKeys メソッドです。

    (参考)Converting the Windows Script Host SendKeys Method

    事前に、$code に WScript.Shell を使用した SendKyes メソッドを埋め込んでおきます。そして、ExecWB を実行する直前で、Start-Process コマンドレットを使ってスクリプトを実行しています。

    こうすることで、ExecWB によって表示されたダイアログを SendKeys メソッドで操作することができます。

    image

    今回は Windows Script を使用しましたが、.NET Framework らしく [System.Windows.Forms.SendKeys] を使うこともできます。ただ、これだとコードが見づらくなってしまうので、個人的にはあまり好きじゃありません。

    ちなみに、「名前を付けて保存」の便利なところは、ファイル名として自動的にWEBページのタイトルを使用してくれるところです。そのため、ファイル名の指定にも SendKey を使用するといった面倒なことをする必要がありません。

    この他 WORD に読み込んで保存するなど方法はいくつかありますが、出力結果を比較すると、やはり ExecWB がベターかなといった感じです。

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

    Windows Phone のセキュリティモデルについて断片ばかりで系統的に語ったことが無かったので、あらためて。

    参考:Download: Windows Phone 7.5 IT Papers - Microsoft Download Center - Download Details

    以下の図は、Windows Phone のセキュリティモデルを模式的に表したものです。

    image

    Windows Phone のセキュリティモデルは「分離の原則」と「最小限の権限」という思想のもとに設計されており、「チャンバー」と呼ばれるコンセプトに沿って実装されています。

    ここで言う「チャンバー」とは、心室や心房などのように仕切られた部屋を意味しています。Windows Phone 上で動作するアプリケーションやドライバーは、必ずいずれかのチャンバーに隔離され、チャンバーごとに定義されたアクセス権限のみを行使することができます。これにより Windows Phone で動作するアプリケーションの独立性と必要最小限のパーミッションによる動作が保障されています。

    チャンバーはセキュリティポリシーの定義によって以下の4つのタイプに分けられています。

    TCB(Trusted Computing Base)チャンバー image

    最も高度な権限を持ったチャンバー。Windows Phone 内のリソースの大部分に無制限にアクセスすることができる。TCB チャンバーはポリシーを変更したり、セキュリティモデルを強制することができる。カーネルとカーネルモードドライバーは TCB チャンバー内で動作する。TCBチャンバー内で動作するアプリケーションを最小限に抑えることが Windows Phone へのアタック面を最小限に減らすことになる重要な要素である。マイクロソフトだけがTCBチャンバーにアプリケーションを追加できる。

    ERC(Elevated Rights Chamber)

    セキュリティポリシーを除く全てのリソースにアクセス可能なチャンバー。ERC は、他の Windows Phone アプリが使用する機能を提供するサービスやユーザーモードドライバを対象にしている。マイクロソフトだけが ERC にソフトウェアを追加することができる。

    SRC(Standard Rights Chamber)

    SRCはプリインストールアプリケーションに与えられる既定のチャンバーである。デバイス全体に影響するサービスを提供するアプリを除き、すべてのプリインストールアプリケーションはSRCで動作する。マイクロソフトの OUTLOOK Mobile 2010 はこのタイプのアプリの例である。

    LPC(Least Privileged Chamber)

    LPC はマイクロソフト以外のアプリ開発者が Marketplace を通して提供できるアプリケーションに与えられる既定のチャンバーである。このチャンバー内に存在するアプリケーションは、分離ストレージへのアクセスを含めた最小限の権限を持っている。チャンバー内で動作するアプリケーションは他のアプリケーションのメモリ領域やストレージなどにアクセスすることはできない。

    以下につづく

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

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

    マイクロソフトに「テクノロジー エバンジェリスト」として入社する人間は、方向性に差はあるものの、それぞれに 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 というプロパティが用意されていますが、これがクレームルールセットです。

    image

    そこで、以下のように入力すると、以下のように、クレームルールセットのみを取得することができます。

    PS C:\> $cp = Get-ADFSClaimsProviderTrust -Name "Active Directory"
    PS C:\> $cp.AcceptanceTransformRules

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Name claims"
    c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer
    =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Primary SID claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"
    , Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Group SID claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Primary group SID claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygrou
    psid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Deny only group SID claims"
    c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/denyonlysid",
    Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Deny only primary SID claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlypri
    marysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Deny only primary group SID claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlypri
    marygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Authentication method claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticat
    ionmethod", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    @RuleTemplate = "PassThroughClaims"
    @RuleName = "Pass through all Authentication time stamp claims"
    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticat
    ioninstant", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
    => issue(claim = c);

    あとは、単純にテキストファイルに出力結果をリダイレクトすれば OK です。

    PS C:\> $cp = Get-ADFSClaimsProviderTrust -Name "Active Directory"
    PS C:\> $cp.AcceptanceTransformRules > crs.bak

    超簡単ですね。そして、Windows PowerShell って素敵ですね。