クラウドコンピューティングに乗り出す際の最大のセキュリティ上の懸念は、顧客情報・書きためたポエム・マル秘画像などを誰かに預けるところにある。「財布などの貴重品は肌身離さず、自分の近いところに置いておく」という今までの常識に反する行動を迫られるのである。クラウド恐ろしや。まして預ける相手がAmazonという140億円の追徴課税を命じられような事業者であればなおさらである。
この誰しも感じる不安を払拭するためにAmazon Web Services (AWS) は自社のセキュリティ対策をまとめた文章を公開している。
Amazon Web Services Security ホワイトペーパー
(PDF注意)
要は「Amazonはこんなに頑張って皆さんのデータのセキュリティを確保していますよ」という販売促進の一環である。しかしよくまとまっていて、Amazonのサービス利用を検討している人だけでなくクラウドコンピューティングのセキュリティを考える人たちにとって一読の価値はあると思ったので、ここでポイントを紹介したい。
特に凄いとおもったところは赤字にしておく。
先に感想
全体を通した私の感想を先に書いてしまえば、非常に野心的なセキュリティに対する取り組みだと思う。特にセキュリティ屋が見過ごしがちな可用性の追求が徹底されている。それは1分止まるだけで、莫大な機会損失が発生するEコマース企業のDNAによるものだろう。今後登場するであろう、国内資本の後発クラウドサービス提供者は少なくともこのラインをクリアしないと市場参入できないのではないか。
簡単に、且つ荒っぽく用語解説
| 略語 | 意味 |
|---|---|
| AWS | Amazon Web Servicesの略。Amazonが提供している各種クラウド系サービスの総称。全容はこちら。 |
| EC2 | Amazon Elastic Compute Cloudの略。平たく言えば仮想レンタルサーバサービスだが、目指しているところは壮大。Elasticは「延び縮みする」という意味。 |
| S3 | Amazon Simple Storage Service の略。仮想ストレージサービス。EC2のOSに接続したり、APIを使った各種クライアントアプリから接続したりして使う。現時点ではお世辞にもSimpleとは言い難い。 |
前置きが長くなったが、以下がAmazonのセキュリティ対策である。
各種認証と認可の取得
AWSは会計監査法人と協力して、SOX法を遵守している。
また、SAS 70 (the Statement on Auditing Standards No. 70) のTYPE IIという認証を取得した。
今後もより厳格な認証基準が設けられればそれを満たすための努力を行う予定である。
その努力の裏付けとして、顧客の中にはAWS上でHIPPA-compliantのヘルスケアアプリケーションを立ち上げているものもいる。
セキュアデザイン原則
Amazonでの開発プロセスはセキュアソフトウェアベストプラクティスに基づいて行われる。
これにはAmazonセキュリティチームによる公式なデザインレビュー、脅威モデリング、リスクアセスメントの実施、ソースコード診断、外部専門家による脆弱性診断が含まれる。
リスク分析レビューはデザインフェーズに始まり、一般公開後まで行われる。
物理セキュリティ
長年のAmazonのサービス提供のノウハウを生かしている。
データセンターは目立たないビル("Amazon"と分からないビル)に収容し、ビルへのアクセスは厳しく制限している。
境界と入り口にはプロのガードマンとビデオ監視システムを備えている。
最新式の侵入者検知システムと様々な電子装置が使用されている。
入室を許可されているスタッフは二要素認証を最低2回パスしないとデータセンターのフロアに到達できない。
訪問者や外部の作業員は身分証明書の提示の後にサインをして入室し、内部では常にスタッフが横に付き添う。
従業員が辞めた場合、AWSに関連する部署を離れた場合には直ちにアクセス権が無効にされる。
顧客のデータにアクセスする可能性のある社員については、法律を遵守しつつも、より詳細な身上調査を実施する。
データのバックアップ
データがバックアップされるタイミングについてはAWSの各サービスで大分内容が異なる。
| サービス名 | バックアップの内容 |
|---|---|
| S3 | データ書き込み時に情報が物理的に別の場所(ヨーロッパとアメリカ東海岸など)にそれぞれ保存される。どちらかに障害発生した際には、別のノードからの復旧を行う。 |
| SimpleDB | S3に同じ |
| Elastic Block Store | データの複製を取得するが、同じ場所に保存される。従ってEBSのデータはS3にバックアップすることを推奨している。ちなみにEBSはファイルシステムを稼働させたままスナップショットバックアップが取得できる。 |
| EC2 | EC2のイメージに接続される仮想ディスクはバックアップされていない。必要があったらS3にバックアップすべし。 |
ネットワークセキュリティ
DDOS対策
AWS APIの各端末は、Amazonという世界最大のオンラインストアを構築した経験を持つエンジニアがそのノウハウを駆使して構築した、インターネットスケールの世界級のインフラに設置されている。独自のDDoS緩和技術が使用されている。またAmazonのネットワークはマルチホーム、マルチプロバイダーである。
Man In the Middle Attacks対策
AWS APIの認証は全てSSLで保護されている。Amazon EC2のAMIはSSHホスト鍵を最初の起動時に作成している。
IPスプーフィング対策
Amazon EC2のインスタンスは送信元を偽装したデータをネットワークに送信できない。Amazonが制御する、ホストベースファイアーウォールがソースIPとMacアドレスの整合性をチェックしている。
ポートスキャン対策
EC2の顧客がポートスキャンをすることはサービス規約違反となる。違反が発見された場合、全て調査の対象となります。違反行為を発見した際にはサポートまでご報告下さい。
またEC2インスタンスに対するスキャンは無意味である。デフォルトで全てのインバウンド通信はブロックされる。security groups機能を使って必要なポートだけを開放する。
通信の盗聴対策
EC2のインスタンスでインターフェースをプロミスキャスモードに変更しても自インスタンス宛でない通信を盗聴することはできない。1人のユーザが2つのインスタンスを保持していて、同じ物理マシンで稼働しているる場合でも同様。
ARPキャッシュポイズニングは技術的対策が施されているためEC2では不可能。
設定管理
AWSのインフラへのメンテナンスや設定変更は全て承認され、記録され、テストされ、実施許可される。サービスに影響が及ぶ変更が加わる場合、メールやWeb(http://status.aws.amazon.com)でアナウンスされる。
EC2のセキュリティ
EC2のセキュリティはホストOS、ゲストOS、ファイアーウォール、署名されたAPIコールの4つによって実現される。
ホストOSのセキュリティ
ホストOSは特別にデザインされ、要塞化されていて、全てのアクセスは記録され監査されている。
ゲストOSのセキュリティ
仮想インスタンスの管理者権限はユーザが持ち、AWS側は仮想OSにログイン/アクセスする権利を持っていない。パスワードベースの認証を避けることをお勧め。
ファイアーウォール
EC2はデフォルトで全ての仮想インスタンスへのインバウンド通信を拒否するファイアーウォールを備えている。通信の制御はプロトコル毎、ポート単位、ソースIP(CIDRでの指定も可能)で条件指定可能。このファイアーウォールはゲストOSからは制御不可能であり、よりセキュリティを高める。これに加えてゲストOS上でiptablesやWindows Firewall, IPsecを使うことをお勧めします。
API
仮想インスタンスの起動、停止、ファイアーウォール操作のAPI利用にはx.509証明書もしくは Amazon Secret Access Keyをつかった認証が必要。このAPIへのアクセスはSSLで暗号化することが可能である。
ハイパーバイザー
Amazonの仮想OS環境はXen Hypervisorを大幅にカスタマイズしたものにより実現される。プロセッサーの利用、ディスクへのアクセスは全て仮想化され、ユーザ及びゲストOSは物理ディスクやCPUへのアクセスを行えない。
インスタンスの独立性を保つ
仮想インスタンスが同一ハードウェア上の他の仮想OSからの影響を受けない仕組みが実現されている。Xenのユーザコミュニティ/開発コミュニティにAmazonは積極的に関与している。AWSのファイアーウォールは物理ネットワークインターフェースとXenの仮想インターフェースの間に実装され、通信の独立度を高めるのに貢献している。AWS独自のディスク仮想化レイヤーはストレージのデータブロックをユーザが利用する直前に、自動的に内容を消去する。前のユーザのデータが残ることはない。とはいえファイルシステム暗号化などをユーザが独自に行うことは良いこと。ユーザが明示的に指定しない限り、同一地域内でのデータの複製はしない。
可用性を保つために(Fault Separation)
EC2は仮想OSの地理的な位置(アメリカ東海岸、ヨーロッパなど)をユーザが選択することが可能。これによりグローバルなリスク分散が可能となる。さらに各拠点(例えばアメリカ東海岸)はその中で複数の都市に施設が分散されていて、各施設間で絶えず内部データの同期が行われている。なお施設間のデータ同期はインターネットを使ってやり取りしている。
S3のセキュリティ
S3はbucket-(ディスク全体)とobject-単位でアクセスコントロール可能。EC2からアクセスする場合でも、インターネットからAPIを使ってアクセスする場合も、HMAC-SHA1署名を使ったユーザ認証を経て、なおかつACLでアクセス許可がされている事が前提条件となる。bucket-(ディスク全体)とobject-単位のACL設定は独立しており、継承されない。アクセスコントロールはAWSのユーザIDもしくはemailアドレス、DevPay Product IDを元に制御できる。
データ管理
S3はSSLでもアクセス可能。オブジェクトがS3から削除された場合、マッピングが即時消去され、数秒以内で全世界に保持されていた複製も含め削除が完了する。
ストレージの廃棄
AWSで使用されるストレージが廃棄される際には、DoD 5520.22-M もしくは NIST 800-88 というガイドラインに沿って適切に処理した上で廃棄される。
なお、本文書は翻訳ではなく私が読んでてポイントと思ったところを抜き書きしたものである。私が使わないSimpleDBやSQSなどのサービスに関する記述は読んでいないし、訳していない。そして、この文書はAmazonの頑張ります宣言であって、現状と食い違いが生じている可能性はある。