プログラマでありたい

おっさんになっても、プログラマでありつづけたい

春のJAWS-UG 三都物語の発表資料 開発環境としてのAWSを真面目に考える

aws


　3/9に行われたJAWS-UG　三都物語の発表資料の公開です。



　大きく二部構成となっていまして、前半は企業でAWSを使う上でのポイントを、後半はDevOpsと絡めてAWSの利点を挙げています。
　AWSの使い方は、公式情報を始め様々な方がブログ等で公開されています。その為、機能面での使い方については困ることは少ないと思います。一方で、AWS自体を安全に運用する為の情報は、まだまだ少ないのではないかと思います。そこで人間を中心にアカウント運用や一括決済、ネットワークの考え方・運用の仕方について話してみました。（改めて資料を見ると、その部分の言及は少なかったですねｗ）
　後半は半ば趣味の話ですが、DevOpsに絡めて話しています。AWSという強力なインフラが出てきたものの、それを単なる仮想サーバとしてでしか使っていないことは多いと思います。各種APIなど自動化の為の方策が沢山あるにも関わらず、手順書に従ってアプリを手動でインストールしていったりと従来どおりのやり方がまだまだ主流だと思います。そこで、今後目指していく方向について語って見ました。デモは全て失敗しましたがｗ


　同じ時間帯のセッションがかなり魅力的なセッションだったので、私の所は１桁かなと御持っていたのですが、意外なことに満員で立ち見の人まで出て来ました。貴重な時間を割いまで聞いて頂けて有難い限りです。今回発表したことにより、自分にとって勉強になることが沢山あり有意義な時間となりました。また、JAWS-UGの方々と沢山知り合いになり、刺激になることも多かったです。今後とも宜しくお願い致します。

Togetterのまとめ


See Also:
今更聞けないCapistranoでリリースの自動化
Capistranoのタスク一覧
JenkinsとSelenium WebDriverでUI層のテストも自動化＆永続化する
Jenkinsでビルド・パイプラインを構築する


参照：
佐々木 拓郎 | 春のJAWS-UG 三都物語 2013

AWS Management Consoleのアクセスログを取る。その１　IAMによるIP制限

aws


　3/9に行われた春のJAWS-UG　三都物語の資料が続々と公開されています。どれも面白いですが、cloudpackさんの"JAWS-UG三都物語 2013 春 よりセキュアなAWS環境 構築事例 〜PCI DSS対応〜"の事例が中々興味深かったです。
　その中の１つに、AWS Management Consoleのログを取るというのがあります。割と実現して欲しいと要望の多い機能ではありますが、2013年3月現在のAWSのデフォルトの機能ではありません。この機能が何故必要かと言いますと、エンタープライズ向けで使うためには必要要件として定義されていることが多いからです。今回の例でもPCI DSS対応の為にも、必須とあるようです。


　デフォルトの機能でないとすれば、どうすれば良いのか？１つはAPIを使って独自に作るという方法です。AWSのサービスは全てAPIが用意されています。つまり画面で出来ることは、全てAPIから出来るということです。であれば、そのAPIを使えば独自でGUIのインターフェースも作れるということです。
　もう１つのアプローチが、今回のcloudpackさんのアプローチです。IAMの機能を使ってAWS Management ConsoleにアクセスするIP制限を行い、アクセス元のIPを特定のサーバからのみ許可して、そのサーバへのアクセスログを全て取るという方式です。いわゆるリバースプロキシタイプです。
　前者はサーバーワークスさんが独自サービスとして展開し、後者はcloudpackさんが事例として紹介しています。中々興味深いです。前者のメリットは、AWS Management Consoleの機能外の部分も、独自のサービスとして組み込めることです。反面、Amazonのサービスの開発のスピードについていかないといけないので、ちょっと大変です。後者はお手軽簡単なので、要望があればサクッと実現出来るのではと思います。


　と言う事で、私も試してみることにしました。長くなりそうなので、IAMのIPアドレス制限とリバースプロキシの設定の２つにわけます。今回はIAMのIPアドレス制限です。

IAMユーザの作成


　マスターアカウントか、IAMの各種権限も持ったユーザアカウントでログインします。そして、ユーザを作成し、Sign-In Credentialsでパスワードを付与します。今回は、LimitedManagementConsoleAccessというユーザ名で作成しています。

パーミッション無しでログイン


　この時点では、Permissionsには何も与えません。その後、ログアウトして再度IAMユーザ用のログインURLから、先ほど作成したIAMユーザでログインします。適当にサービスを選ぶと、次のように権限がありませんという画面が出るはずです。

IPアドレス制限付きのパーミッション設定


　次に、またIAMのアカウントの編集権限のあるアカウントでログインします。そしてIAMで該当ユーザにPermissionsのAttache User Policyで権限を与えます。Policy Generatorで、権限を与えたいServiceとResource Nameを選びます。その後がポイントなのですが、Add Conditions (Optional)で、ConditionをIPAddressでKeyをaws:SourceIpを選びます。Valueの部分を自分の外向きのグローバルIPアドレスを指定します。これでおっけいです。



出来たパーミッションは、こんな感じになるはずです。(51.44.71.80/32から、EC2に対するフルアクセス)

{
  "Statement": [
    {
      "Sid": "Stmt1363006771539",
      "Action": [
        "ec2:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "51.44.71.80/32"
        }
      }
    }
  ]
}


　確認の為、IAMアカウントでログインして、設定したサービスが使えるかを確認しましょう。指定したIPアドレスからは無事に使えるはずです。また、それ以外のIPアドレスからは、依然権限がないというメッセージがでるはずです。

マスターアカウントの制限について


　今の設定は、IAMアカウントについてのIPアドレスについての制限です。では、マスターアカウントについては、どう制限するのでしょうか？実は、この方法では制限できません。では、どうしたら良いのでしょうか？１つの解は、AWS Multi-Factor Authentication などを使ってマスターアカウントをパスワードのみの認証ではアクセス出来ないようにすれば良いのではないでしょうか？そして、認証デバイスの貸出管理をすると言った方法が考えられます。私個人的としては、マスターアカウントはIAMアカウントを作ったら極力使わないように運用設計するのが安全ではないかと考えています。

まとめ


　IAMユーザに対するIPアドレス制限は簡単に出来ました。次回はApachもしくはNginxを使ったリバースプロキシサーバの構築を書いて、完成させたいと思います。


　なお余談ですが、今回はIAMユーザに付与する権限等については特に言及していませんが、ここを極めると安全な運用設計が出来ます。例えば多い事故として、インスタンスをStopするつもりが間違えてTerminateしてしまったとか。人間は必ずミスを起こします。ですので、普段の運用で使うアカウントにはTerminate権限を与えずStopだけ付与するといったことで、事故を未然に防ぐことが出来ます。


参照：
JAWS-UG三都物語 2013 春 よりセキュアなAWS環境 構築事例 〜PCI DSS対応〜
当日セッションスライド資料を公開します！ | 春のJAWS-UG 三都物語 2013