【Management】Windows Update Powershell Module (1)

久しぶりに Windows Update をスクリプトから実行しようかなぁと思って PowerShell のコマンドレットを探していたら、標準では提供されていないんですねぇ。全く気づいておりませんでした。 となると、VBScript のように Microsoft.Update.Session を呼び出すしかないものかと思っていると、なんと便利なモジュールが提供されていました。 Windows Update PowerShell Module http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc さっそく使ってみましょう。 まずはダウンロードして ZIP ファイルを開いてみてください。PSWindowsUpdate フォルダが格納されているはずです。この中にこのモジュールを構成するスクリプト群が格納されています。 これらのファイルは「インターネットゾーンからダウンロードしたファイル」なので、必ず「ブロックの解除」を実行しておきましょう。でないと実行できません。 【PowerShell】一括で「ブロックを解除」する ~ Windows PowerShell 編 その1 http://blogs.technet.com/b/junichia/archive/2012/01/13/3475162.aspx 【PowerShell】「ブロックを解除」するためのメソッドを追加してみる http://blogs.technet.com/b/junichia/archive/2012/01/15/3475439.aspx 【Management】一括で「ブロックを解除」する streams コマンド編 http://blogs.technet.com/b/junichia/archive/2012/01/12/3475091.aspx ブロック解除が完了したら、PSWindowsUpdate フォルダを、PowerShell のモジュール用フォルダに保存します。 モジュール用フォルダの場所を確認するには、以下のように PowerShell コンソールから環境変数 PSModulePath を確認します。 PS C:\windows\system32> $env:PSModulePath C:\Users\junichia\Documents\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerSh ell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\ (参考)Windows PowerShell: Windows PowerShell…

0

【IAM】DAC その5 ~ Dynamic Access Control のアーキテクチャ(3) - PAC と Kerberos Pre-authentication(RFC 6113)による拡張

なんだかどんどん深みにはまりつつある ダイナミックアクセス制御の解説シリーズです。。。でもお好きな方にはたまらないですよね(と信じつつ)。 2013 年 7 月以降には、DAC Deep Dive 1日コースのセミナーを開催しようかと考えております。東京以外でも開催したいのので、ぜひご要望をお寄せくださいませ。 さて、前回までの投稿は以下の通りです。 【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】DAC その 1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx 【IAM】DAC その 3 ~ Dynamic Access Control のアーキテクチャ(1) http://blogs.technet.com/b/junichia/archive/2013/05/07/3571125.aspx 【IAM】DAC その 4 ~ Dynamic Access Control のアーキテクチャ(2) ー FSRM が必要な理由 http://blogs.technet.com/b/junichia/archive/2013/05/10/3571884.aspx 前回は「なぜダイナミック アクセス 制御」に「FSRM(File Server Resource Manager」が必要なのか?について解説しました。その中で、DAC…

0

【IAM】DAC その4 ~ Dynamic Access Control のアーキテクチャ(2) ー FSRM が必要な理由

Windows Server 2012 から利用可能になった ダイナミックアクセス制御 に関して、細々と掲載を続けるシリーズです。前回までの投稿は以下の通りです。 【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】DAC その2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx 【IAM】DAC その3~Dynamic Access Control のアーキテクチャ(1) http://blogs.technet.com/b/junichia/archive/2013/05/07/3571125.aspx 今回は、DAC を利用するのにファイルサーバー側に FSRM(ファイルサーバー リソースマネージャー)が必要な理由について解説しておきたいと思います。 FSRM(ファイルサーバー リソースマネージャー)は既にご存知かと思いますが、念のために紹介しておきます。詳細は以下を参照ください。 ファイル サーバー リソース マネージャーの概要 http://technet.microsoft.com/ja-jp/library/hh831701.aspx FSRM はもともと Windows Server 2003 R2 で初めて実装されました。それが 2008 → 2008 R2 →2012 と進化し続け、今に至っています。 FSRM はひとことで言えばストレージをより高度かつ合理的に管理するための機能セットです。Windows Server…

0

【IAM】DAC その3~Dynamic Access Control のアーキテクチャ(1)

以前の投稿につづき、今回は Windows Servevr 2012 が提供する DAC のアーキテクチャについて解説します。この辺をご理解いただくと、多くのエンジニアの方に「おぉ、やってみたい」と思っていただけるかと。   【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】 DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】 DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx まずは以前の投稿でも使用した以下の図をご覧ください。DAC では「リソース側の属性」と「ID 側の属性」のマッチングを行い、条件が合致したときにアクセス権が適用されます。 ちょっと運用イメージが想像しずらいでしょうか? 現実の世界にもこのような仕組みは存在しています。例えば"ある種の結婚相談所"を思い浮かべてみてください。 あくまでも私の想像ですが、結婚相談所の場合、女性は出会いたい男性の属性を事前に定義しておく必要があるのでしょう(たぶん)。結構相談所側は、女性の要求と、条件に合致した男性から女性へのコンタクト権限(アクセスルール)を定義しておきます。もちろん、このときアクセスルールにはある程度女性側のニーズを反映させる必要があるので、複数のルールを作成しておく必要があるかもしれません。男性はどういった女性が登録されているかは把握可能ではあるものの、アクセスルールに合致しなければインスタントメッセージさえも送ることは不可能です。 このモデルでは、結婚相談所が両者のニーズの中間地点でアクセス管理を行っています。もし結婚相談所によるアクセス管理が無かったとしたら、一切のアクセス制御は女性自身が行う必要があります。これはとても面倒です。 えっと何の話でしたっけ?あ、DACですね。DAC に話を戻しましょう。 DAC によるアクセス管理の全体像をざくっと図にすると以下の通りです。 ここで3人の主要な登場人物について理解しておきましょう。 ソース アクセスポリシー リソース ソースとは、リソースにアクセスする主体を指します。つまり、ユーザーやデバイスのことです。ソースは Active Directory ドメインに定義されたオブジェクトであり、ldap 属性を持っています。 リソースとはファイルサーバー上の”フォルダ”や”ファイル”のことです。リソースには「分類属性」と呼ばれる特別な属性を定義することができ、これを使用してアクセス可能なソースを制限することができます。 アクセスポリシーとは、その名の通りアクセスを制御するためのポリシーです。正式日本語名称「集約型アクセスポリシー(Central Access Policy)」と呼ばれ、その名称から”集中管理された”アクセスポリシーであることがわかります。「集中管理」が何を意味するかといえば、もちろん「Active Directory ドメイン による集中管理」のことです。 上の図を、さらに詳しく書いたのが以下の図です。…

0

【IAM】 DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか

前回の投稿は以下の通りです。 【IAM】 DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx この投稿では、前回の投稿をふまえ、「なぜ企業のアクセス管理にDACが必要なのか」という点について書きたいと思います。 DAC が「Expression(式)ベースのルールによるアクセス管理」であることは前回の投稿で書いた通りです。 ここで疑問を持つ方がいらっしゃると思います。 「アクセスルールを管理するのは誰なのよ?」 当然の疑問です。 IDの属性を管理するのは「ID管理者」。リソースの属性を管理するのは「リソース管理者」です。両者を結び付ける「アクセスルール」を誰が管理するのか? 従来の ACL ベースのアクセス管理では、ルールを管理していたのは「リソース管理者(またはリソースのオーナー)」です。それが最も合理的であると考えられてきました。しかし、「社内統制」という観点では、しばしば不合理な問題が発生しうるのもこの方式です。 各所に IT が浸透し多く部門間でデータを共有するようになると、その取扱いが極めて煩雑になります。リソースの提供者の多くは「アクセス権の管理手法」を正確に理解していませんから、しばしば設定ミスや怠慢等によってセキュリティ上重大なリスクが発生してしまうことがあります。 こうした問題を軽減するために「企業レベルのアクセスルール管理」へのニーズが高まっています。企業内の専門部隊が、社内リソースのアクセスルールを集中的に管理するという考え方です。 もちろん、すべてのリソースがその対象となるわけではないでしょう。しかし、確実に社内統制が必要なリソースは存在します。そうしたリソースに対しては、統制されたアクセスルールを適用することで、これまでよりも安全にリソースを管理できるようになります。 ということで、冒頭の疑問への回答は以下の通りです。 「アクセスルールを管理するのは、社内のセキュリティチームである」 セキュリティチームがリソースのアクセス権に関して行う作業は以下の通りです。 1. 重要な社内リソースへのアクセス権に関してセキュリティポリシーを策定する 対象リソース:どのサーバーの、どういう属性を持ったリソースを対象にするのか 対象ユーザー:どういう属性を持ったユーザーを対象にするのか アクセスルール:対象リソースに対して対象ユーザーがどのようなアクセス権を持つの ここで注意していただきたいのは、対象リソースを明に(C:\Data とか)指定するわけではないということです。あくまでも対象となるリソースの「条件」を定義するのだという点に注意してください。 条件には、所属以外にも、担当プロジェクトや役職などが考えられますし、単純なところではデータの重要性(外部公開、社外秘、社員のみ など)を定義する必要もあるでしょう。また、より厳密に管理するのであれば「データがどういったコンプライアンスフレームワークに属するか」といった定義も必要になるでしょう。例えば以下のようなフレームワークが考えられます(日本にとっては重要でないものもあったりなかったりですが。。。)。 CObIT http://ja.wikipedia.org/wiki/COBIT EU Data Protection Directive(EU データ保護指令) http://www.caa.go.jp/seikatsu/kojin/H21report1a.pdf FACTA(外国口座税務コンプライアンス法) http://www.nri.co.jp/opinion/kinyu_itf/2011/pdf/itf_201108_6.pdf FERC/NERC CIP FISMA(Federal Information Security Management Act of 2002)…

0

【IAM】 DAC その1 ~ グループベース RBAC の破たん?

DAC と書くと「 discretionary access control(随意アクセス制御)」を思い浮かべてしまう方も多いと思いますが、ここでは「Dynamic Access Control(ダイナミックアクセス制御)」を指しています。 ※ちなみに RBAC とは Role-Based Access Control の略ですが、詳しくは本文中で。 Windows Server 2012 から実装された新しい機能「ダイナミックアクセス制御」。みなさんご利用でしょうか?以前以下の投稿をしましたが、あまり見られていないですね(笑)。なんか、あのころの AD FS を見るようだなぁと。。。 【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx そこで、なぜ DAC なるものが必要なのか?という点についてまとめておきたいと思います。 ACL ベースのアクセス制御 「アクセス制御」という言葉があります。アクセス制御については説明するまでもありませんが、「ユーザーがアクセスしてもよいかどうかを評価するプロセス」のことです。 ご存知の通り、従来マイクロソフトが採用しているアクセス制御方式は、「ACL 方式」です。 ACL とは Access Control List の略で、中には 「ACE(Access Control Entory)」と呼ばれるエントリーが格納されています。ACE にはユーザーやグループを識別するための SID(Security ID)とアクセス権が格納されており、これによってユーザーのアクセス権が識別されます。ACL に複数のACEが格納されている場合、これらは基本的に「OR」で評価されます(ただし、同じSIDが複数のACEに格納されている場合には、その中の一番厳しいアクセス権が採用されるという大原則があります)。 ACL は「静的」です。つまり、誰かが手で設定しなければ変わることはありません。つまり一度アクセス権が与えられたら、ACL から ACE を削除するか、ACE を変更するまで永遠に現在のアクセス権が与えられ続けます。そこで、組織間で人材が移動してもリソース側に直接手を入れる必要が無いようにするため、マイクロソフトでは「グループにアクセス権を与える」方法を推奨しています。グループにアクセス権を与えることで、アクセス権の制御を「グループのメンバーシップの変更」で置き換えようという考え方です。こうすれば、リソース側のアクセス権を直接操作する必要はなくなります。こうしたアクセス権管理の方式を AGDLP と呼んでいます。 A :Account G…

0

【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書

以前、以下の投稿をしました。 http://blogs.technet.com/b/junichia/archive/2012/12/10/3539674.aspx ダイナミックアクセス制御はとても面白いテクノロジーなのですが、かなり複雑なので手を付けている方は少ないのではないでしょうか。 そこで、現在実施しているハンズオンセミナーで使用している資料から、ダイナミックアクセス制御の部分を抜粋して公開しました。 解説編と演習編に分かれています。 演習環境はシンプルで、以下の2つの仮想マシンを用意していただければOKです。 ドメインコントローラーが構成された Windows Server 2012(フルインストール) ドメインのメンバーとなっている Windows Server 2012(フルインストール) 細かな設定は必要ありません。すべて演習の中で一から構築していきます。 Windows 8 の Hyper-V でも問題なく演習できます。 是非、社内の勉強会等でも活用してください! Dynamic Access Control 解説編 Dynamic Access Control 演習編  

0

【IDM】Active Directory Federation Service 2.1 の新機能

※この投稿は Office 365 Advent Clendar 2012 に参加しています。 軽い話題ですんません。 私の大好きな Active Directory Federation Service 2.0 は、Office 365 の爆発的人気に伴い、今ではすっかりフィールドに浸透しました。もう、「AD FS なんて知らない、聞いたことない」という方はいらっしゃらないでしょう。 そんな中、いまひそかに熱い注目を集めているのが Windows Server 2012 に標準実装された Active Directory Federation Service 2.1 です。新しい Hyper-V や Failover Cluster の陰に隠れて目立たないことこの上ないですが、地味ながら確実に進化しています。 Active Directory フェデレーション サービス(2.1)の概要 http://technet.microsoft.com/ja-jp/library/hh831502.aspx 上記サイトにも書かれている通り、AD FS 2.1 の新機能として3つが挙げられています。 役割の1つとしてサーバーマネージャーまたは PowerShell でインストールできるようになった AD FS 役割をインストールすれば、add-pssnapin をすることなくコマンドレットが使用できる Kerberos チケットからクレームを取得できるようになった ここで大いに気になるのは 3…

0

1024 ビット未満の鍵長を持つ証明書を無効にする更新プログラム (KB2661254) の公開について

すでにセキュリティチームの Blog にも掲載されていますが、こちらにも転載しておきたいと思います。 概要 暗号の 2010 年問題 (暗号の危殆化) や、Flame マルウェアによる証明書への脅威を背景に、マイクロソフトは RSA アルゴリズムに対する強化策として、2012 年 8 月 14 日 (米国時間) に、鍵長 1024 ビット未満の暗号鍵を持つ RSA 証明書をブロックする更新プログラム (KB2661254) を公開しました (マイクロソフト セキュリティ アドバイザリ 2661254)。この更新プログラムの適用により、鍵長 1024 ビット未満の RSA 証明書を使用する Web サイトが閲覧できなくなる、S/MIME メールの送受信ができなくなる、また 1024 ビット未満で署名された ActiveX コントロールやアプリケーションのインストールに失敗するなどの影響が出ます。影響の詳細は、「1024 ビット未満の暗号キーをブロックする更新プログラム (KB2661254) を 8/14 に公開 – その 2」でも解説していますのでご確認ください。 背景 2004 年 8 月に米国商務省国立標準研究所 (NIST) が発表した暗号強度強化に関する勧告…

0

【WP for IT Pros】IRM 保護された電子メールや Office ドキュメントの扱われ方

ご存知のように、Windows Phone 7.5 では IRM 保護されたメールやOfficeドキュメントを読むことができます。今のところ、IRM 保護されたメールやドキュメントを参照できるのは、Windows Phone だけです。 ※ 残念ながら、現時点では Windows Phone から IRM 保護の設定はできません IRM とは Information Rights Management の略です。Active Directory Rights Management Service(AD RMS)を導入することによって、IRMで保護されたデータ使用することができます。 では、IRM とは具体的にどのようなメリットをもたらしてくれるのでしょう?ご存知の方も多いと思いますが、ちょっとだけ復習しておきましょう。 情報漏えいを抑止するにはデータの暗号化が基本です。しかし、人間が読むためには暗号化されたデータを解除しなければなりません。危険はここに存在します。いくら暗号化していても、かならず暗号化を解除する瞬間が必ずくるのです。データの受信者に悪意があったり、リテラシが低かったりして、暗号化が解除されたデータを印刷されたり、外部に転送されたら、その瞬間暗号化して送信した意味が無くなります。 そこで、暗号化以外の強制力が必要になります。 つまり、「受信者に許可された権限」を保持したまま電子メールやOfficeドキュメントを流通させることで、データの漏えいリスクを低減することができます。 Windows Phone では、電子メールとOfficeドキュメントとでは、IRM の扱われ方が少しだけ異なっています。 知っているから何か得する…ということでもないのですが、IT Pro にとっては興味があるところだと思いますので両者の違いについて少し解説しておきます。 ■ 電子メールの場合 Windows Phone の Outlook Mobile から電子メールの同期要求を受け取ると、Exchange はユーザーをチェックし、同期対象となる電子メールおよび添付ファイルに対して、一旦 IRM 保護(暗号化と権限付与)を適用します。 受信者が電子メールの参照権限を持っていれば、Exchange Server 上で暗号化を解除し、ユーザーの権限を付与したまま Windows Phone…

0