Systems Manager＋AWS Confg、Config Rulesのセッションをレポート
初めてのOpsSecJAWS、まずはOps側から運用を楽にする工夫を披露
2018年7月5日、Ops-JAWSとSecurity-JAWSの共催イベントである初めての「OpsSecJAWS」が開催された。「OpsSecJAWSからはじまる異世界（AWS）狂想曲」と題したイベントは、セキュリティとその運用において気をつけたいことがテーマ。Amazon Chimeによってリモートも参加できるようになっており、会場メンバーもあわせると、240人を超える登録があったという。前半となるOps側の2本のセッションをレポートする。
Systems Manager＋AWS Configで運用をもっと楽にする
冒頭、「AWS ConfigとSystems Managerのちょっといい話」というタイトルで登壇したOps-JAWSの会澤 康二さん。大手SIer勤務の会澤さんはSystems Managerのすごいところについて「AWSの責任共有モデルにおいて、本来ユーザーがしなければならないOSより上の管理を、AWSのサービスで実現しているところ」と説明。OSに入らずとも、アクセス管理サービスであるIAMのポリシーに応じたアクセス管理で運用管理できるのがオススメだという。
Ops-JAWSの会澤 康二さん
続いて、会澤さんは大手SIerを例にDevとOpsのよくある関係について語る。アプリケーションを開発するDev側は規模としては大きいが、Ops側にインフラを作ってもらった関係上、メンテナンスもOps側に任せられると思っていることが多い。一方、Ops側は初期開発が終了すると、OS以下の安定運用に注力しがち。そのため、ミドルウェア周りで両者がお見合いしているというパターンが多いという。
DevとOpsのお見合い状態
こうした事態を解消するため、会澤氏はOps側がSystems Managerを用いることで、担当レイヤーを上げて行くべきと主張する。「よくDevOpsと言われますが、Ops-JAWSの私からすると、Opsの方がレイヤーを上げて行き、Dev側に提言を上げて行くべき」と語る。Systems Managerでは、AWSのコンポーネントをはじめ、導入しているソフトウェアのインベントリまでまとめて収集できる。さらに、AWS Configを使えば、ソフトウェアのインストールや削除、追加といったインベントリを追跡してくれる。
とはいえ、普段からAWSを使ってない人にとってみると、こうした情報もあまりチェックされないので、会澤さんの会社ではAWSの構成パラメーターシートをExcelに出力しているという。具体的には、インベントリの変更を検知したAWS ConfigがLambdaをキックすることで、ExcelをS3に出力する。「現場のエンジニアはソースコードやコンソール見ればいいじゃんとなりがちだが、マネージャーは普段使っているExcelのようなツールを使いたいはず。そこは下手に波風立てないで、一工夫していい関係を作るべき」という会澤さんのコメントは含蓄が深いと感じられた。
AWS Config RulesでIAMポリシーを自動適用する方法
続いて「AWS Config RulesでIAMポリシーを自動適用する話」というタイトルで登壇したのは、サーバーワークスの斎藤 裕樹さんだ。2012年に新卒でサーバーワークスに入社し、Webアプリの受託開発と運用チームを担当。2016年からはカスタマーサポートと社内ワークフローの自動化を担当しており、「サーバーワークスにいながらSIをやらない珍しい技術者」だという。
サーバーワークス 斎藤裕樹さん
現在、斎藤さんは顧客や社内向けに複数のAWSアカウントを管理しているが、操作してほしくないリソースがあったため、制限の強い権限を付与していた。その結果、ユーザーは自由にポリシーを作れなくなり、担当者と斎藤さんの間で複数のやりとりが発生していた。「意図せずにリソースに触れられるのは避けたいが、スピード感はカイゼンしたかった」（斎藤さん）ということで、IAMリソースにタッチした段階で特定のポリシーをアタッチする仕組みをConfig Rulesのカスタムルールで作ったという。
具体的にはIAMリソースを作成した段階で変更管理ログがS3に保存されたら、Config RulesのカスタムルールでIAMユーザー・ロールであるかどうかを確認。その上で、Lambda Functionを起動し、作成・更新されたIAMリソースに所定のポリシーがアタッチされているかをチェックする。もしアタッチされてなければ、ポリシーをアタッチして再評価し、すべてをコンプライアントな状態にするまでを実行する。ポイントとしてはポリシーは自身の操作は制限しておくが、リソースの削除ができなくなるため、ポリシーのデタッチはできるようにしておくことだという。
IAMリソースを強制アタッチする自動化
こうした自動化の結果、IAMリソースの作成やポリシー適用のチェックを管理者がやらなくても済むようになった。斎藤さんは「Lambdaがあればなんでもできるというのが今回の感想。Config Rulesも想像以上に簡単に使える」とまとめ、AWS側で用意されたマネージドルールでできないことも、カスタムルールで作り込めるとアピールした。
週刊アスキーの最新情報を購読しよう
