» 標準と勧告のブログ記事

結論、概要レベルだと一緒です。
 

でも日本語訳がちょっと違う、折角なので比較のために原文、日本語v1.1・v1.2 を並べてみました。※違いがあるところだけ併記。
 

ちなみにバージョン別の各国版はどれも PCIDSSの公式サイト からPDFのダウンロードができます、規約に同意してね。
 

では比較版を。全く意味はないが変更について至極どうでもいいコメントもしてみよう。
 

Build and Maintain a Secure Network
安全なネットワークの構築・維持

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  要件1： カード会員データを保護するためにファイアウォールを導入し、最適な設定を維持すること
• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
  要件2： システムパスワードと他のセキュリティ・パラメータにベンダー提供のデフォルトを使用しないこと

 
全く変わらない、ファイアウォールは運用の要件が変わってたがここでの表現は同じ。
 

Protect Cardholder Data
カード会員データの保護

• Requirement 3: Protect stored cardholder data
  要件3： 保存されたカード会員データを安全に保護すること (1.1)
  要件3： 保存されるカード会員データの保護 (1.2)
• Requirement 4: Encrypt transmission of cardholder data across open, public networks
  要件4： 公衆ネットワーク上でカード会員データを送信する場合、暗号化すること

要件3、「安全に保護」だと二重表現っぽいということかな？頭痛が痛いみたいな。
保存の仕方や情報の範囲にも要件はあるので、「保存された」→「保存される」は良い変更だと思ったら、資料のうち詳細のところでは元のままだった。
 

Maintain a Vulnerability Management Program
脆弱性を管理するプログラムの整備

• Requirement 5: Use and regularly update anti-virus software
  要件5： アンチウィルス･ソフトウェアを利用し、定期的に更新すること
• Requirement 6: Develop and maintain secure systems and applications
  要件6： 安全性の高いシステムとアプリケーションを開発し、保守すること

Implement Strong Access Control Measures
強固なアクセス制御手法の導入

• Requirement 7: Restrict access to cardholder data by business need-to-know
  要件7： カード会員データへのアクセスを業務上の必要範囲内に制限すること
• Requirement 8: Assign a unique ID to each person with computer access
  要件8： コンピュータにアクセスする利用者毎に個別のID を割り当てること (1.1)
  要件8： コンピュータにアクセスできる各ユーザに一意のIDを割り当てる (1.2)
• Requirement 9: Restrict physical access to cardholder data
  要件9： カード会員データへの物理的アクセスを制限すること (1.1)
  要件9： カード会員データへの物理的アクセスを制限する (1.2)

 
要件8、「する」を「できる」に変更してきました。外的要因への対応？といった所でしょうか、イメージしやすくなったかも。
要件9はなぜかここだけ「こと」のみカット。他に比べてここにはむしろ必要な部類なんじゃあなかろうか…？
 

Regularly Monitor and Test Networks
定期的なネットワークの監視およびテスト

• Requirement 10: Track and monitor all access to network resources and cardholder data
  要件10： ネットワーク資源およびカード会員データに対するすべてのアクセスを追跡し、監視すること (1.1)
  要件10： ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する (1.2)
• Requirement 11: Regularly test security systems and processes
  要件11： セキュリティ・システムおよび管理手順を定期的にテストすること (1.1)
  要件11： セキュリティ・システムおよびプロセスを定期的にテストする (1.2)

 
要件10、「資源」→「リソース」、ちょっとハイカラな表現で演出してきましたね。
なのに全体で AおよびB を CおよびDする となってちょっとオシャレ度ダウンな印象、およびおよびな。
要件11もハイカラですね、でも1.1の意訳っぽい表現のほうがマッチしていたかも。
 

Maintain an Information Security Policy
情報セキュリティ・ポリシーの整備

• Requirement 12: Maintain a policy that addresses information security
  要件12： 情報セキュリティに関するポリシーを整備すること (1.1)
  要件12： 情報セキュリティポリシーを整備する (1.2)※

※要件12、PCIDSS資料本文のところでは「従業員および派遣社員向けの情報セキュリティポリシーを整備する」になってます。見出しから変えすぎじゃない？
 
セキュリティにまつわるエトセトラ、的な表現から単体指名になってますね。まあ 大体あってる ので分かりやすくなった、ここは潔くてナイス。
ただ本文のほう、従業員および派遣社員向け だけじゃなくて サービスプロバイダ向けもあるので本文の追加見出しに不足があります、注意。
 
 
 

v1.1 で見られる文末を「・・・すること」で統一するというポリシーがなくなった模様。
あと範囲が限定的すぎた表現を適切になるよう変更したといった感じですかね。
「・・・すること」全廃でもいいと思うけどなあ。

前編からの続き
telnet があれば何でもできる！ と言ってみたかっただけですが。
 

ということで、telnet2本使いによるFTPファイル転送を実際にやってみる。
実験にはIISのFTPサーバを使い、サーバ間のファイル転送ができるかを確かめた。
 
 

突然つまづく、最近はデフォルトセキュア(寄り)なのか…

リハーサルとして一通り試していたら、PORTコマンドの所でどうしてもつまづく。
パケットキャプチャしたら、PORT発行後もIPによる通信すら しに行っていない様子。IISの設定を見直すためにMSへ。

Microsoft TechNet : サーバーからサーバーへの FTP 転送
http://technet2.microsoft.com/WindowsServer/ja/library/f5c810d2-a0cd-44a9-ba14-0ed5c09264bb1041.mspx?mfr=true

 
なるほどそうか。最近はそんなことやらないからか、単に脆弱性の脅威からか、デフォルト設定ではできない。レジストリをいじってFTPサービスを再起動しないといけなかった。
レジストリ変更箇所は下記。

これで問題はなかろう、よそへのPORTコマンドもちゃんと受け付けてくれる。
 
 

そして実験へ

test.txtと言うファイルを転送してみる。

OK、うまく行った。
 
 

次はどうしよう。
定番の「telnet があれば メールの送信ができる」や、「telnet があれば HTTPコンテンツを受け取れる」、あたりでやっておきたい。

telnet ですかー！？
と、分からないかもしれないネタはこの辺にして、「telnet があれば、サーバ間でファイルの転送ができる(前編)」と題して FTP (File Transfer Protocol) の仕様を確認するコラム。
 
 

前置き、PASVコマンド

FTPというと、通常のPORTコマンドを使うやり取りを初めて理解したときは驚いた。
「PORTコマンドの発行を受け付けたサーバは、接続元ポートTCP/20 でクライアントにむけてTCPセッションを張りに来る。」
そうやって接続されたセッションがデータ転送ポートとして、ファイルリストのテキストデータや、バイナリデータの転送に使用される。
 

嘘やん、そんなのこちらポート空けてないのにどうすんの？って思う節があるかもしれないが、最近のファイアウォールやルータはその辺をヨロシクやってくれて、意識しなくてよいようになっている。
しかしそうではないルータの下にいるFTPクライアントの為に、PASVを使うという手順がある。
 
 

FTPサーバがPASVコマンドを受け付けると、任意のポートでLISTEN のTCP状態を取り、クライアントに通知します。
 
    [PASV] → [227 Entering Passive Mode (192,168,10,15,239,11)]
 
カッコ内がカンマ区切りで、IPアドレス・待ち受けポートです。このメッセージからは「IPアドレス：192.168.10.15、ポート：61195」 でLISTENしますよ、と言うこと。ちなみに 61195 は 「239 * 256 + 11」 で計算します。
 
 

PASVに割りこんだらどうなるの？

PASVでポートの通知を受けたFTPのクライアントは、当然LISTENしているポートにTCPセッションを張りに行き、データはこのポートから送信されます。
 
と、ここでPASVで教えてもらったポートに telnet で接続するとどうなるか試した(※実験はPASVも telnet で発行しました。)ら、ちゃんとセッションが張れる。
そのまま最初に接続したコマンド用のセッションで、LISTなど発行すればPASVで張ったほうのセッションからリストデータが、RETRをすればファイルの中身が流れてくるといった具合。
 

基本的に接続元の制限などない模様なので、これはこれで危なっかしいとも思えるが、もうちょっと突っ込んで考えてみる。
 
 

PORT と PASV の組み合わせで、と思ってRFCを参照する

使わないから意識していなかったが、FTPはサーバ同士のデータ転送という役割を与えられたプロトコルでもある、と言うのを形だけ知っていた。
上の割り込み実験から、「PASV で待ちうけ、PORTで接続」 とすればサーバ間の転送ができるんじゃないかと思って、RFCを読んでみた。
   RFC:959(原文)(日本語訳)
 

すると、「5.2. CONNECTIONS」 の所にしっかり書いてあった、今でこそ一般的ではないやり方だけど、RFCでは一番シンプルなFTPの使い方としてサーバ間のデータ転送が紹介されている方法だった。
 
 

telnet2本張って サーバ間のデータ転送

コントロールはクライアントから、データの転送は2台のサーバ間で。
サーバA(SV-A)からサーバB(SV-B)にファイルを転送したい場合、ざっとこういう手順で達成できるはず。図が崩れてたらごめんなさい、Firefoxだと一応きれい。
 

┌──────┐        ┌──────┐
│    SV-A    │        │    SV-B    │
└──────┘        └──────┘
        ↑                    ↑
        │                    │
        │telnet 21           │telnet 21
        │  ┌──────┐  │
        └←│    Ctrl    │→┘
            └──────┘

                        LISTEN
┌──────┐        ┌──────┐
│    SV-A    │        ★    SV-B    │
└──────┘        └──────┘
        │                    ↑
        │                    │
        │                    │PASV
        │  ┌──────┐  │
        └─│    Ctrl    │→┘
            └──────┘

                        LISTEN
┌──────┐        ┌──────┐
│    SV-A    →───→★    SV-B    │
└──────┘        └──────┘
        ↑                    │
        │                    │
        │PORT(SV-B)          │
        │  ┌──────┐  │
        └←│    Ctrl    │─┘
            └──────┘

┌──────┐→data→┌──────┐
│    SV-A    ＝＝＝＝＝＝    SV-B    │
└──────┘        └──────┘
        ↑                    ↑
        │                    │
        │RETR(File)          │STOR(File)
        │  ┌──────┐  │
        └←│    Ctrl    │→┘
            └──────┘

さて、手元に実験できるサーバがないので今度試してみよう。
後編につづく

インターネットの技術標準文書としていわずと知れたRequest for Comments(RFC)、参考リンク：Wikipedia
HTTPやSMTPをはじめ、インターネットで利用されるプロトコルの仕様を確認したいときなど使います。
 
基本的には実際に使用されているもの中心のスタンダードトラック(STD)文書を見ればよいのですが、ネットで軽く検索するくらいでは情報が多いし最新かよく分からないし大変ですよねー
…と思っていたら、公式がまず情報まとめ用の文書を作っていることを結構最近になって知りました。
 
STD文書の1番はSTD全体の目次になっており、常に最新のRFCを発行(今はRFC5000)して差し替えられているため、とりあえず見ておけばよいというものになっています。
 
最新の情報を確認したらあとはゆっくり日本語訳さがすか、なければ頑張って原文読むか。
とりあえずSTD1.
 

RFC公開サイト：RFC-Editor Web Pages
→STD1番直接リンク