AWSのOffice of the CISOも登壇した第12回Security-JAWSダイジェスト

DevOpsからDevSecOpsに向かうアカウント認証基盤の取り組み

　Amazon Web Service（AWS）とセキュリティをテーマに開催されてきた勉強会「Security-JAWS」。2019年1月21日に開催された第12回勉強会では、セキュリティ運用とは切っても切れない「ログ」に関するセッションが目立った。そして最後には米国からの豪華ゲストも登場し、参加者に向けてAWSのセキュリティに対する姿勢を紹介した。

re:Invent 2018で登場した「CloudWatch Logs Insights」、その実力は？

　セキュリティ担当、特に運用を担っている際に避けられないのがログの調査だ。たとえば、不審なファイルを開いてしまった端末から外部のIPアドレスへの接続状況を調べたり、脆弱性を探るような通信を探したりと、内外問わずログのチェックをする機会は多いはず。

　Amazon Web Services Japanの中島智広氏は「皆さん、それをどうやってますか。Amazon ElasticSearchを使ったり、grepなどワンライナーを作って運用するケースが多いと思うけれど、セキュリティ調査の目的はその時々でけっこう変わるもの。その上ログの種類もまちまちで、時にはクラウドとオンプレミスにまたがりコストと手間がかかることもあって、なかなかうまく運用できていないのではないか」と指摘した。

Amazon Web Services Japanの中島智広氏

　そこを補ってくれそうなのが、CloudWatchの一機能である「CloudWatch Logs Insights」だ。「重要なポイントはAWSとオンプレミスの両方をサポートしていること。なので、双方のログ管理を統合できる」（中島氏）。対象と期間を選択し、クエリを記述するだけで使える簡単さと検索の強力さを兼ね備えている。また、従量課金制で利用できること、高速でスケーラブルでありしかもフルマネージドという利点もあるという。ちなみに300GBのログを取り込み、月に1000GB分保存するような使い方の場合、課金額はおおむね500ドル程度になるそうだ。

　中島氏は、parseやfilter、statsといったCloudWatch Logs Insightsのコマンドを組み合わせ、ログに簡単にフィルタをかけて必要なものを取り込んだり、ソートをかけたり、グラフ化したりといったデモを紹介。「アドホックなログ調査の多いセキュリティ運用には便利だし、運用改善のきっかけにもなる」と述べ、ぜひ使ってみてほしいと呼び掛けた。

CloudWatch Logs Insightsのデモ

DevOpsの文化をベースにアカウント認証基盤を守る取り組み

　ソニーネットワークコミュニケーションズでは、ソニーグループが提供する複数のサービスで利用できるユーザー認証基盤の開発・運用を担なっている。OAuth 2.0やOpenID Connectに対応したアカウント基盤で、同社の小野寺剛氏らは、「利用者に、より安全なアカウントサービスを提供することをミッションにして提供している」と説明する。

ソニーネットワークコミュニケーションズ 小野寺剛氏

　この基盤はDevOpsスタイルで開発・運用され、公開後はAWS WAFによって外部のさまざまなな攻撃から保護されている。WAFというとどうしてもポリシーのチューニングが面倒というイメージもあるが、ソニーネットワークコミュニケーションズでは元々根付いていたDevOpsの文化を元に、モニタリングを元に最適なルールを設定し、適切な運用を実現しているという。小野寺氏はその経緯を紹介してくれた。

　ソニーネットワークコミュニケーションズには元々、DevOpsの文化が定着し、CI/CDを効率よく回せる体制が整っていた。しかしアカウント認証基盤を作るとなると、そこにリスク評価や脆弱性検査、不正侵入検知といった、さまざまな「重たい」セキュリティ対応も求められることになる。「今まで通りの方法でやっていては運用が回らないし、工数も増える。セキュリティのアクションをいかに開発フェーズの段階でオートメートしていくか」（小野寺氏）という考えから、DevSecOpsやシフトレフトに取り組んだそう。

　けれど、地に足の着いた形でこの取り組みはうまくいきました。その要因を、小野寺氏は「元々DevOpsの文化が根付いていたため、無理せず着実にできたのではないかと思う」と振り返る。

　印象的だったのは、コミュニケーションの重要性について語ったこんな言葉。「すごく大事だなと思うのは、チーム内の連携だ。連携といっても、『席が近くて話しやすい』というよりも、開発とインフラ、セキュリティ担当が同じチームとして体系的に情報共有できる仕組みがあることが重要。われわれには以前からデイリーのアラートや週次のインシデントを共有する枠組みがあった。こうしたコミュニケーションがあってはじめてDevSecOpsが円滑になるのかなと思っている」（小野寺氏）。

　さて、ユーザー認証基盤だが、サービスインの前からSQLインジェクションをはじめ、さまざまな攻撃を想定してAWS WAFのルールを導入していた。ただ、攻撃手法はその時々によって変わる。またWAF ACL（Condition）の数に上限もあることから、小野寺氏らはモニタリング結果を踏まえながら臨機応変に対応してきたという。

　時には、通常ではあり得ない規模のリクエストが突発的に来たり、ID情報を扱うアカウントサービスの特性を見越した攻撃もあったそうだが、「落ち着いてリクエストを分析し、その攻撃の特徴を捉えることが大事。それには、ログ、つまり測れるものを集約してクエリできるようにしておくことが大事」と小野寺氏。DevOpsの文化があり、ログを見るのが好きな人がいたことに加え、計測可能な状態を実現したことが鍵と言えそうだ。

　ログを分析し、攻撃の関連性を見出したならば、たとえばジオロケーションマッピングを行ってサービス提供国以外からのアクセスをブロックしたり、今はあり得ない古いバージョンのブラウザは止めるといった対処を行いました。「一時しのぎでも、恒久対応の時間を確保できるだけでも全然違う」（小野寺氏）

　また、IPアドレス単位でエラーレートを見ながらブロックするよう、オートブロックの仕組みも改善していったそう。「エラー回数がある一定のレートを超えたらブロックするようにしているが、攻撃者側も対策を学習してさまざまな手を試し、どこがそのしきい値なのかを探ってくる。一般ユーザーに影響が生じず、かつ不正リクエストを引っ掛けられるようチューニングしている」と、日々細かく調整している。

　そして、ひとまず落ち着いたと感じた頃に、また新手の攻撃がやって来たときに、ちょうどAWS WAFのマネージドルールが登場したため早速導入してみたそう。アプライアンスのWAFは高いイメージがあったが、AWSマーケットプレイスのものはずっと安くて手軽なこともあり、「入れて試して、合わなければ別のものを試すといった具合に試行錯誤しながら開発を進め、安定した運用ができている」（小野寺氏）

　それもこれも、やはりモニタリングができる体制を整え、DevOpsが根付いていたからこそ。こうした経験を通して、AWS answersのベストプラクティスの実用性を実感するとともに、「あまり複雑化させずシンプルなルールでログを解析し、モニタリングすることが大切だ」とあらためて感じたそうだ。