2014年11月30日日曜日

AWS KMS が使えるのに気付いたので、早速試してみたメモ

re:invent で発表された、AWS Key Management Service が使えるようになっているのに気付いたので、早速使ってみることにしました。
このサービスは管理的には非常に重要でキーを安全に共有したいとか、キーがどれだっけ?とか、緊急の対処が必要なのにキーが見つからないとか、そういう状況に陥らないようにするために、こう言ったサービスが非常に重要だったりします。
サポートされているリージョンは以下の通りです。東京でも使えますね。

http://docs.aws.amazon.com/kms/latest/developerguide/regions.html

Region NameRegionEndpointProtocolSupport Date
US East (Northern Virginia) Regionus-east-1kms.us-east-1.amazonaws.comHTTPS11/12/2014
US West (Northern California) Regionus-west-1kms.us-west-1.amazonaws.comHTTPS11/12/2014
US West (Oregon) Regionus-west-2kms.us-west-2.amazonaws.comHTTPS11/12/2014
EU (Ireland) Regioneu-west-1kms.eu-west-1.amazonaws.comHTTPS11/12/2014
EU (Frankfurt) Regioneu-central-1kms.eu-central-1.amazonaws.comHTTPS11/12/2014
Asia Pacific (Singapore) Regionap-southeast-1kms.ap-southeast-1.amazonaws.comHTTPS11/12/2014
Asia Pacific (Sydney) Regionap-southeast-2kms.ap-southeast-2.amazonaws.comHTTPS11/12/2014
Asia Pacific (Tokyo) Regionap-northeast-1kms.ap-northeast-1.amazonaws.comHTTPS11/12/2014
South America (Sao Paulo) Regionsa-east-1kms.sa-east-1.amazonaws.comHTTPS11/12/2014

対応しているサービスは以下の通りです。

  • Amazon Redshift
  • Amazon Simple Storage Service
  • Amazon Elastic Block Store

データストアとして使うサービスで暗号化がサポートされているサービスは全て使えるようです。個人的な趣味としては、RDSのEBSでつかえるのかなぁというのが気になります。

それでは、早速、使ってみたいと思います。単独のサービスとしては、management console には表示されません。 IAM のメニューの一つとして、あります。
早速 Getting Started Now してみましょう。
なんだかわからないキーがポツンと一つだけあります。クリックしてみると、”Default master key that protects my EBS volumes when no other key is defined” とあるので、EBSを暗号化するときに利用する、デフォルトのキーのようです。EBS暗号化をすでに利用している人はうっかり消さないようにしましょう。実際 management console 上では消せないようにガードされているようです。


よく考えずに、Create Key してみます。


エイリアスを入力しなければいけないようなので、とりあえず適当な名前を入力します。


IAMユーザーの選択を求められたので、汎用に使っている adminitorator 権限(ようするに制限なし)のユーザーを選択しました。


もう一回 IAM ユーザーの選択を求められます。よく読むと、キーの管理者とキーの利用者を別に設定できるようです。これはセキュリティ的によく考えられた設計だと思います。でもここでは同じユーザーを選択しました。よろしくないですね。

こんな感じでキーのポリシーが作成されました。キーの管理者権限と、使用者権限が別に設定されています。
次に進むとこんな感じで、キーが作成されています。初期で作成されたキーは洗濯できなくて、新しく作成されたキーば選択可能になっています。キーの削除も可能なようです。


クリックするとこんな感じの画面になって、キーの管理者と使用者を指定できるようになっています。


キー自体をアップロードしたり、ダウンロードしたりはできないようです。

実際どのようなユースケースが想定されるでしょうか。

例えば、研究開発部門で極秘のプロジェクトが進行していて、同社内でも他部門には知られたくない研究データがあったとします。もちろ他社の産業スパイなどにも注意が必要です。そのデータはEBSに格納されています。KMSを利用して、権限を限定して、かつEBS暗号化を利用することで、同社内でもデータを利用することを制限することが可能です。
人事データや給与データなども該当するかもしれません。

もっと簡単なユースケースでは、例えば18禁ビデオと、それ以外でアクセス可能な権限を分けるとかw

何れにしてもセキュリティ管理的には重要な機能が追加されたと思います。

2014年11月20日木曜日

クラウド運用について気づいた6つのこと

きょう、日本MSP協会の記念すべき第1回の会合に参加させていただき、たくさんの議論のなかで、気付き(というか思いつき)が幾つかあったのでメモしておきます。

運用は Managed それとも Operation

"運用でカバー" という言葉が示す通りとかく運用担当は雑用係になりがちです。そもそも運用とは何か?という問いかけに明確に答えられないのが実情だと思います。手順書をもらって作業するのが運用ということになりがちです。
これはただの operation だと思います。
operation を超えて Managed になるには何が必要なのだろうか? という問いかけに答える必要があります。

サービスカタログの必要性

Managed として認めていただくためには、 Managed Service として何が提供されるのかを明確にする必要があると感じました。そのためには Service Catalogue の充実が必要になると思いました。では Service Catalogue の内容として何が必要なのでしょうか? 幾つか思いつきですが並べてみます。

コスト最適化

MSP という業種は Managed 業務のアウトソーシングだと思います。アウトソーシングである以上、自社でやるよりもコストメリットがあることを訴求しなければいけないと思います。そのためにはサービス内容を貨幣価値で評価する必要があり、管理会計的な手法や、オペレーショナルリサーチ的な手法が必要になるように思います。同一コストであれば、デリバリーされる内容が自社運用するよりもレベルが高いとか、同じサービス内容であればコストが安いことなどをお客様や経営層に訴求する必要があると思います。

IT 統制の重要性

Managed Service の重要な課題となるのは IT 統制、特にセキュリティへのコミットメントではないでしょうか。本当に IT 統制を適用するとシステムの規模によりますが、それだけで莫大なコストがかかります。MSP に任せれば セキュリティを含めて IT 統制、コンプライアンスは万全だと言われるような Service Catalogue の整備が必要だと思います。

運用設計の重要性

DevOps ではないですが、クラウド時代の運用は自動化手法が重要になってくると思います。そのためには、システム設計の段階から運用、コンプライアンスに関して重要なアーキテクチャを提案する必要があると思います。例えば、Immutable infrastructure 化する手法の提案などがあると思います。とりあえず作っちゃったから、あと運用よろしくでは IT 統制のコンプライアンスを取得するのは難しくなると感じました。

職業的ディシプリン(規律)の確立

IT 統制の中で最もリスクが高いのは、某通信教育会社の事例を引き合いに出すまでもなく、Human Factor だと思います。MSP に任せて安心だと思っていただくためには、マックス・ヴェーバーのプロテスタンティズムの倫理と資本主義の精神」ではないですが、やはり倫理的な規範を示す必要があると思います。その規範の表明としてMSPチャーター(憲章)のようなものを制定する必要があるように思います。MSPチャーターに従うことが運用プロフェッショナルとして表明することなるようになったらいいなぁと思いました。

以上、とりとめもなく書いていますが多くの方のご意見を賜りたいと思います。