他人にばれにくいパスワードの決め方

みなさんは普段どのようなパスワードを使っていますか?
まさか、「password」とか「1qaz2wsx」とかを自分のIDに対して使ってないですよね~(`ω´)笑

パスワードを決める際、いくつか気をつけられることがあると思います。
たとえば、
+ 自分のユーザ名、フルネーム、固有名詞を含んだパスワードの禁止
+ アルファベットは(大・小)を使用する、数字・記号をまぜる
+ 定期的にパスワードを変更する
+ 文字の少ないパスワードの禁止

などが思いつきます。
どうですか?意識的に、安全なパスワードを使えているでしょうか?
セキュリティポリシーが強めだと、複雑なパスワードじゃないと作成できないので
その時はがんばって複雑なものを考えるけれど、結局忘れてしまったり。
紙にメモしてもそのメモを紛失してしまって逆に危なかったり。。なんてこともあると思います。

そんなときに、パスフレーズを使ってみてはどうでしょうか?
これはけっこういいと思います☆


パスフレーズとは

パスフレーズとは、自分の身近な題材を文章にし、その頭文字をとってパスワードにする方法です。
一見ランダムな文字列に見えるけれど、自分にだけは身近な文字なので覚えやすいというメリットがあります。
下の図のように、頭文字をとる+さらに文字の置き換えをするとよいですね!

Alt text

Kerberos認証でわからないこと

ドメインの認証方式のひとつであるKerberos認証。
Kerberos認証は、Windows認証方式の中で最も強固なもので、パスワードそのものを送信しないため、ネットワークを介して資格情報が盗まれるリスクが極めて低いという特徴があります。

このしくみでちょっとわからないことがあるのです。

ドメインにログオンすれば、TGTによってドメインにログオンしていることが保障され、ドメイン内のほかのコンピュータにアクセスするための認証は必要ありません。

ワークグループの場合は、ユーザ名に対するパスワードを格納するデータベースを個々のコンピュータで管理しているから、他のコンピュータにアクセスするときは、そのコンピュータで有効な資格情報を再び入力しなくてはいけないってことはわかるのです。

でも、Kerberos認証の場合、どのタイミングでコンピュータがドメインにログオンしていることが保証されるのかなぁ…TGTの流れをもう少し理解しないといけなそうです。
解決したらまた更新しますね。


Kerberos認証のしくみ

Alt text

①クライアントで資格情報(ユーザ名とPass)が入力されると、ユーザ名をドメインコントローラに送信する。
②ユーザ名を受信したドメコンは、ユーザがドメインにログオンしていることを示すTGT(Ticket Granting Ticket)(グランディングは承諾するの意味)と呼ばれるチケットを発行する。
③ユーザ名に対応するパスワードをデータベースから取り出し、TGTをパスワードを使って暗号化する。
④暗号化されたTGTをクライアントに送信する。
⑤ユーザは受信したTGTを自分が入力したパスワードを使って暗号を解除する。この時正しいパスワードを入力していれば、暗号化を解除し、TGTをとりだすことができる。

※TGTは時刻にずれがないことが前提で、サーバとクライアントで5分以上のずれがあると失敗する。

パッチを適用するセキュリティ対策~WSUS~

久々の更新になってしまいました(´・ω・`); セミナー勉強会、出張などここ最近はイベント盛りだくさんでした。まとめたいことは山ほどあるのですが。。。

今回は、先日2日間にわたって受講してきた「WindowsServer運用実践セキュリティ編」で勉強してきたことのひとつ、Microsoft社が提供する更新プログラム適用制御用のサーバ・アプリケーションWindows Server Update Services 通称WSUS(ダブルサス)についてまとめます。

みなさん個人の端末は、自分のタイミングでアップデートをかければよいですが、会社のたくさんある端末達のパッチ適用はどうやったら効率的なのか、WSUSのサービスと合わせてみていきましょう。


そもそもパッチ適用はなんで必要?

まず下の図をみてください。(わかりにくい、デザインのイケてなさはごめんなさい・・・)         Alt text    

アプリケーションは、主にこの4つの手法で脆弱性をねらった攻撃をうけます。    

一昔前は左上の「メールの添付ファイルを実行」といった手法が主でしたが、最近は多様化してきているようです。
たとえば右上の「USBメモリ内のプログラム実行」。これはUSBを挿されたらオートラン機能が働いて悪いプログラムが実行され…アウトです。
このような「攻撃」事態を防ぐのはとても難しいので、「脆弱性」をなくす対策が重要になってきます。   

Microsoftは、このような脆弱性に対する更新プログラムを、毎月第2火曜日の翌日にリリースしています。
だからといって、リリースされたプログラムをむやみにインストールするのはとても危険な行為です!!
それは、Windowsの更新が既存の業務アプリケーションに影響することがあるからです。
アップデートをかけたらIEのバージョンがあがってしまったが、使っている業務アプリが新しいIEに対応してなくて使えなくなった、どうしよう!なんてことが起きないためにパッチ適用は次のサイクルで行うとうまくいくでしょう。

パッチ管理サイクル

パッチ適用は、調査→識別→評価→展開 のサイクルで行います。それぞれどのような作業になるのか下記に記します。
Alt text  

  • 調査・・・コンピュータの状態を調査
    管理しているコンピュータの確認、コンピュータごとにどのようなアプリケーションを使用しているか確認します。
  • 識別・・・必要なパッチを識別
    調査での確認結果をもとに、適用する必要があるパッチ、適用しないパッチを識別します。(サービスパックやIEのバージョンアップは大幅な更新になるので普通はすぐにはしないと思います)
  • 評価・・・パッチをテスト導入
    パッチ適用後に、OS、Office、業務アプリなどが正常に動作するか確認します。チェックリストを作成しておくとよいでしょう。
  • 展開・・・各コンピュータへ導入
    正常動作が確認できたら、各コンピュータへ導入します。ここでWSUSを使います!

Windows Server Update Servicesとは

Windows Server Update ServicesとはMicrosoftが提供する、Windows OSやアプリケーションの更新プログラム、デバイスドライバ等をクライアントPCの「自動更新」コンポーネントを利用して配布する、クライアント・サーバ・モデルのアプリケーションです。
・・・ちょっとわかりにくいですか?
たくさんあるコンピュータのパッチ管理を、一台ずつ設定するのではなくサーバ側で一括設定することができるのです。
WSUSを運用するのに必要なのは、WSUS用サーバ、ドメインコントローラだけです。WSUSも簡単にインストールすることができます。
どのようなしくみなのか図と合わせて簡単に説明していきます。 Alt text 

一般の個人用端末であれば、クライアントから直接MicrosoftUpdateにつないでパッチをインストールしますが、WSUSを使った場合は、WSUSサーバがMicrosoftUpdateからパッチをダウンロードしてきます。
ダウンロードしてきたパッチから、必要なパッチを識別します。コンピュータは、OS別、用途別などにグループをわけることができ、適用するパッチもそれぞれグループに合わせて選択することができます。 ドメインコントーラでは、グループポリシーで各クライアントのWindowsUpdateの設定(更新元の変更)を制御します。
かなりはしょって説明してしまいましたが、以上の設定をすることで、クライアントのパッチ管理をすることができます。

またこのWSUSは下の図のように、MicrosoftUpdateに接続するWSUSサーバ(アップストリーム)の下に、さらに中継地点を複数置くことができます。(ダウンストリーム)
クライアント数が多い企業では、支店ごとにダウンストリームを置くことで負荷分散ができます。 Alt text 

以前の職場ではこのWSUSでパッチ管理を行っていましたが、今の職場では学期末ごとに1台ずつ設定している現状なので、導入できそうか検討してみたいと思います。