クラスメソッドの臼田さんが「これだけはやっとけ」をわかりやすく説明

運用に丸投げしてない？ AWSでよりよいセキュリティライフを送るポイント

2019年04月12日 09時30分更新

文● 高橋睦美

　午前中に行なわれたにも関わらず、立ち見まで出たJAWS DAYS 2019の「AWS環境のセキュリティ運用(設計)をはじめてみよう」というセッションでは、みんなお世話になっているブログ「Developers.IO」でもおなじみ、クラスメソッドの臼田佳祐さんが登場。AWS環境をセキュリティを保ちながら運用していくには、「運用に丸投げするのではなく、設計段階からきちんと考え、必要な設定を行なうことが重要」と強調した。

どこから見てもクラメソな臼田佳祐さん

運用は設計の段階から始まっている

　セキュリティという言葉に抱くイメージはさまざまだろうが、多くの人にとっては「つらそうで責任重大」「その割にルーチンワークで、つまらなそう」という感じではないだろうか。確かに、日々セキュリティグループを管理し、脆弱性の情報をチェックしてはパッチを当てて……という作業は、あまりクリエイティブには思えないかもしれない。

　臼田さんはそんな背景を踏まえ、さらに「そうした作業は本当に人力でやっていく必要があるか、と問いたい」と述べた。オンプレミスの時代ならば、人力に頼るしかなかった作業は多かった。しかしクラウド時代に突入した今は違う。「せっかくクラウドを使うなら、オンプレミスのときよりも辛くなっては元も子もない。なるべく楽に、それでいて強く守っていくというところにスコープを当てたい」（臼田さん）

　では、どうすれば楽にセキュアな環境を作れるのだろうか。「セキュリティに限らず、運用は現場で起こっているものではなく、設計の段階から始まっている。作るだけ作って、後の運用については考えないと言うのはナンセンス。設計段階から運用のことを考え、なるべく問題をつぶしておくべき」と臼田さんは述べた。

皆さん使っていますか？ AWS利用時に必要な最低限のセキュリティ機能

　その上で臼田さんは、セキュリティを考慮したAWS環境を作る基本的なポイントをいくつか紹介した。「最低限」といってもいろいろあり、詳細は公開資料で説明されているが、AWS環境を使うに当たってはまず、AWSに対するAPIの操作をすべてロギングする「AWS CloudTrail」、AWSリソースの構成・変更を可視化する「AWS Config」、AWS上で使える脅威検知のマネージドサービス「Amazon GuardDuty」、同じくマネージドなDDoS対策サービス「AWS Shield」は少なくとも有効化し、利用すべきだという。

　「料金はまったく無料ということはないが、費用対効果は非常に高いので、絶対これらのサービスは有効化してほしい。JAWS DAYSが終わって週明け出社したらすぐ有効化してください」（臼田さん）

　また、障害が発生してサービスが停止してしまう、というのもセキュリティインシデントの1つだ。臼田さんは、アベイラビリティの確保という観点からオートスケーリングやマルチAZ、Amazon Elastic Load Balancing（ELB）によるNATを利用し、必要に応じてAmazon CloudFrontによるキャッシュやAWS WAFといったサービスを導入しておくのがセキュアな基本構成だとした。

一般的にセキュアな構成

　逆に、「EC2を1台のみで直接インターネットに面するのはダメなパターン。冗長化されていないし、アクセス急増時にスケールもできない上、サービス提供用と管理用アクセスとで同じIPアドレスになり、いろいろとリスキーだ。設計の基本は『Design for Failure』なので、障害が起きることを前提に設計すべき」（臼田さん）という。

　AWS利用時に考えなければいけないのは、こうしたリソースの構成のみではない。大事な要素が「セキュリティグループ」だ。会社によっていろいろなパターンがあるだろうが、臼田さんは「ネットワークACLは最低限の設定に留め、アクセス制限の設定はセキュリティグループに寄せて行なう方が運用は楽。また、セキュリティグループは『役割』ごとに分けて作るとよい」とアドバイスした。

最低限のライン

　また、クラウド運用でよくあるのが、一時的にアクセスを許可しなければならないケースだ。「こうした一時的なアクセスを許可する際は、セキュリティグループを直接書き変えるのではなく、別途作業用のセキュリティグループを作成し、それを一時的にアタッチ、デタッチするべき。万一レコード書き換え中にミスをしてしまっては、元も子もなくなってしまう」と臼田さんは、ありがちなミスに注意を呼び掛けた。

　もう1つ大事なポイントがIAMユーザーの管理だ。「『IAMベストプラクティス』が用意されているため、権限回りの管理は基本的にこれに沿って行なうべき。始めたばかりのときは、安易に『Administorator』や『PowerUser』を付けてしまいがちだが、本番環境に出すときには手を抜かないでほしい」（臼田さん）。さらに、人間が利用するIAMユーザーについては多要素認証を必須にすること、人が使わないIAMユーザーは最低限に抑え、IAMユーザーから発行するクレデンシャルの量も減らすことといったポイントを紹介した。

　もちろん、あまりにガチガチにするとクラウドならではの良さが損なわれる恐れがある。「IAMロールの作成を管理者だけに限定すると開発者がつらくなる。開発者も生成できるようにする代わりに、リテラシー教育を行ったり、AWS Configのルールを活用して制限を加えるといった形で運用してほしい」（臼田さん）

　他にも、バックアップの取得と障害時の復旧手順の整備、サードパーティ製セキュリティ製品の活用など、いくつか留意すべき事柄があるとした。

　もう1つ忘れてはならないポイントが監視の設計だ。「異常に気付くには監視が必要。それも運用に丸投げせず、設計段階から何を監視するかを決め、そのためのダッシュボードやアラームも最初に作ってください」と臼田さんは述べた。例えばEC2ならばCPUとメモリとディスクといったリソースがそうだし、他にもALBやターゲットグループの負荷状況、レスポンスタイムなどさまざまな指標がある。それらの中からどれを見るかを決め、用途ごとにダッシュボードを作り、担当者ごとに見られるようにしておくといいそうだ。

　その上「アラートを出し、それが出たらどんなアクションを実行するかもだいたい自動化できるので、できるものは自動化しましょう。通知もJSONで長いものが出てくるため、メールよりは、整形してSlackなどに投げるのがいいと思います」とした。

「AWS Systems Manager」を活用してセキュリティ運用の自動化を

　ここまでがAWS利用時に抑えておくべき最低限のセキュリティだ。臼田さんはこうした対策を実施した上で、「AWS Systems Manager」（SSM）を活用したセキュリティ運用の「自動化」を目指してほしいと述べた。

　AWS SSMは、AWSの運用を支援するツール群の総称だ。インスタンスにエージェントを入れておけば、あとはログインしなくてもいろいろな作業を行なうことができ、運用上も便利だという。

　具体的には、EC2にログインせずに任意のコマンドを発行できる「Run Command」のほか、あらかじめ定義したドキュメントに沿って順位処理を行なう「Automation」、時間や実行間隔を指定して一定の処理をスケジューリングできる「Maintenance Windows」といった機能があり、これらを組み合わせれば週次・月次処理やメンテナンス作業を楽に行なえるという。

　セキュリティの観点から注目したいのが「Patch Manager」だ。「深刻度がクリティカルなパッチはすぐに適用し、それ以外のパッチは1週間後に適用する」といったルールを「ベースライン」として定めておくと、それに沿って自動的にパッチ管理が行える。適用状況を確認するスキャンも実施可能だ。

　臼田さんは「パッチ管理を自動化するツール群はそろっている。ただ、だからといって何も考えずに適用してはいけない」と釘を刺した。

　というのも、パッチ適用によってアプリケーションの動作に支障が生じては元も子もないからだ。まず検証環境を用いて正常に動作することを確認し、問題がなければ本番環境に適用するという具合にやり方や判断基準をきちんと考えた上で、AWS SSMを用いて「脆弱性のチェック」「検証環境における正常性の確認」「本番環境への適用」といった処理を自動化していくプロセスを提唱した。詳細な手順はブログ「AutoScalingで1台ずつ自動的にパッチを当てるSSM Automationやってみた」でも紹介しているという。

　パッチ適用という作業自体は自動化できるが、そのためにも「きちんと設定を行ない、テストの手法や評価仕方を決め、パッチベースラインを決めてほしい。運用に丸投げせず、設計段階で決めて自動化することが重要だ」と臼田さんは述べた。

　セキュリティは大切だが、すべての項目をやりきるとなると負担が高いのも事実。「1つの考え方として、バックアップを取って復旧できる状態にした上でとりあえず全部パッチを当てていく『日和見アップデート』というのもありだと思う」と臼田さんは言う。というのも、万が一にも、既知の脆弱性を突かれてセキュリティインシデントが発生してはシャレにならないからだ。

　「パッチを適用してちょっとサービスが落ちました、と言う方がマシ。サービスが落ちたら原因を追及して改善すればいいけれど、やらずにセキュリティインシデントが起きたらどうしようもない」（臼田さん）