Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます!

AWS re:Inforce 2019に参加してきました

こんにちは。Speee 開発基盤ユニット 兼 セキュリティ推進室 エンジニアの @iogi です。

6月25日、26日の2日間、ボストンで開催された AWS re:Inforce に参加してきました。

reinforce.awsevents.com

AWS re:Inforce とは

セキュリティに特化したAWSのイベントで、昨年のre:Inventでアナウンスされ、今回が初回開催となっています。 今年は、(AWSではなくAmazonではありますが) AIやMachine Learningにフォーカスした re:MARS も初開催されていましたね。

会場は、Boston Convention & Exhibition Center で、日本でいう幕張メッセ的な展示会場です。先日、開催されたAWS Summit Tokyoの会場と比較すると、若干広くはあるものの、余裕があって、回りやすくてちょうどよかったです。re:Inventと比べると、単一会場ですし、日数も2日ととてもコンパクトです。

キーノート、セッションについては、動画が公開されていますので、興味があるセッションが無いか眺めてみることをおすすめします。

以下、参加したセッションのうち面白かったものをいくつかピックアップしていきます。

キーノート

ひとことで言えばAWSでのセキュリティにフォーカスした基礎的な紹介でしょうか。

恒例の? 軽いOracle disもありましたが、AWSで各レイヤでのセキュリティが強固であること、セキュリティのために多くのサービスがあることなどがメインでした。 re:Invent であれば、当分試せないPrivate Previewのアナウンスなどもありますが、そういったものは全くなく、AWS ControlTower と、AWS Security Hub の正式リリースと、当日リリースが発表されたのも VPC Traffic Mirroring くらいで、ある意味誠実かと思います。

開催地はボストンで、アメリカの金融の中心であるウォール街のあるニューヨーク、政府所在地であるワシントンD.Cにも近い東海岸エリアということで、そういう層へ好まれるキーノートかもしれません。GovCloudにサービスがリリースされるのは時間もかかるので、Previewのサービスがいったいいつ来るかって話もありそうですよね…

youtu.be

re:Inforce周辺のリリースでは、PrivateLink対応など、地味だけどセキュアな環境をつくるためのアップデートがリリースされていました。

また、上には含めていませんが Fargate など、GovCloud対応サービスのリリースが増えたりしていました。

セッション

セッションは、re:Inventと同じように 200 (Intermediate)、300 (Advanced)、400 (Expert) までレベリングされ、カテゴリ分けされていますが、400レベルが少なく、Technical Deep Diveといった感じのセッションはあまり無かったのが残念なところでした。 このあたりは、より深いセキュリティのセッションがあればと来年以降に期待したいです。

GRC328 - Account automation and temporary AWS credential service

Riot Games が、多数存在するAWSアカウントについて、 AWS Step Functions と Lambda で作成自動化した話と、アクセスキーの利用をなるべく避けてSTSでの一時的認証情報を利用するようツールを作った話です。

動画: AWS re:Inforce 2019: Account Automation and Temporary AWS Credential Service (GRC328) - YouTube

アカウント作成については、Speeeでも、AWS Organizationsでアカウントを作成を行っており、一部自動化していますが、ローカル実行のスクリプト群になっていて、Step Function化はよいなと思ったので取り入れたいと思っています。

後者については、Riot Games でもアクセスキー、シークレットのペアが漏洩し、インスタンスが大量に起動されるというインシデントが発生し、それからアクセスキーを減らすためにツール "Key Conjurer" を作り始め、アクセスキーをそこそこ減らせてきたという話です。

漏洩時のリスクが高いアクセスキーは利用を避け、IAM RoleやSTSによる一時的な認証情報の利用が推奨されています。EC2インスタンスやLambdaなど、AWSで稼働するサービスでは、IAMロールが基本使えますし、コンソールはFederationでIAMユーザの利用を (ルートアカウント以外は) 排除することができます。

しかしながら、開発時にローカルのPCなどからAPIを叩きたいとなると、アクセスキーは通常必要になってきます。AssumeRoleだけできるアクセスキーだけ作って、AssumeRoleを利用してアクセスとかも実現できますが、configファイルが漏洩するとリスクは同じですし、たくさんアカウントやRoleがあったときに、それ config に手で書いてメンテするの?という課題があります。

Key Conjurer では。GUIとCLIが提供され、ADの認証情報でログインしたあとは、新しく認証情報を取得する際にはpush通知でMFAを行い、あまり手間かからず認証情報を取得できて使い勝手がよさそうでした。

そして、同日オープンソースで公開されたので、検証してみたいと思っています。 SSOにOneLogin、MFAにDuoが利用されていますが、SpeeeではSSO、MFAに Azure ADを利用しているので*1、差し替えて使えそうかも含めて見てみたいです。

github.com

SCP や IAMポリシーまわり

AWS OrganizationsでのSCP (Service Control Policy) や、IAMポリシーまわりのセッションが多くありました。

同一Organizationの中からであればアクセスを許可するであったり、処理実行元のIAM Roleに付与したタグをベースにアクセス制御を行うといった、以前できなかったことが可能になっていたりするので、ポリシー設計の際には古い知識を当てにせず、今できるベストな方法を把握していかないなと思いました。

SDD314: Enforcing security invariants with AWS Organizations は、OrganizationsでのSCPでの活用方法

動画: AWS re:Inforce 2019: Enforcing Security Invariants with AWS Organizations (SDD314) - YouTube

SDD350: Scale permissions management in AWS with attribute-based access control は、IAM Roleのタグベースでのアクセス制御の説明

動画: AWS re:Inforce 2019: Scale Permissions Management in AWS w/ Attribute-Based Access Control (SDD350) - YouTube

SEP401: Security benefits of the Nitro architecture

仕事関係なくハードの話っておもしろいですよね! re:Inforceで一番テクニカルでセキュリティな話だったかもしれません。 Nitro ベースのインスタンスタイプ が増えてきましたが、どういう思想で作られたか、パフォーマンスやセキュリティ、またEBSやCloudWatchといったAWSの機能とどう繋がっているのかといったアーキテクチャの説明でした。 新しいインスタンスタイプが単純に早くてうれしいという恩恵を受けていますが、自前のコントローラを作ってまでやる意味ってなんだろうという部分の理解が、より深まります。

動画: AWS re:Inforce 2019: Security Benefits of the Nitro Architecture (SEP401-R) - YouTube

その他

Security Learning Hub という名前で、スポンサーブースや、Builders Faireなどが配置されていました。

スポンサーブースは、数こそは多くないものの、セキュリティ関連のソリューションが集まっていて、勢いのある製品や、日本ではまだ聞いたことはないけど面白そうな製品などがあり、よかったです。ちょうど、インシデント検知などのソリューションを検討中なので、いろいろと検証など始めてみようかと思っています。

ワークショップや、CTFやSecurity Jamといったイベントも実施されていて、興味は惹かれるのですが、セッションが開催されているなか、時間のかかるものに参加できるかというと悩ましく参加せずじまいでした。

印象的だったのは、幕間に表示されるスライドで "You're making history" と表示されることでした。

f:id:i_ogi:20190625131748j:plain

"Make History" は、Amazonの仕事のポリシーである "Work hard. Have fun. Make history," というフレーズの1つで、初回開催のカンファレンスの参加者ということで、今まさに歴史を目撃し、一緒に作っているんだと感じました。

来年は、テキサス州ヒューストンで開催ということで、大規模ゆえに開催地に制約のある re:Invent と違って、場所が変わる楽しみもありますね。

また、キーノートにてSecurity Roadshowが世界各地で開催されることがアナウンスされ、東京にも来るようです。追って、 AWS Security Blog にてアナウンスされるようです。

所感

社内のAWSアカウントをどう管理していくか、アカウント作成の自動化、AWS Configでのモニタリングなど、現在の業務へのヒントをいろいろと与えてもらえました。 気持ちが高まっている今の間に、今後の整備に活かしていこうと考えています。

一方、Security Hub、Control Towerが、すでにOrganizationsを利用していると現状未サポートというのは、カンファレンスに間に合わせただけでGAではないのではという気持ちがありますが、一旦待ち。

AWS Config Rulesについては、複数アカウントがあると高価になって、必要最低限しか設定する気がなかったり、RDSが存在しないアカウントにはRDS関連のConfig Ruleを入れないようにといった面倒なことをやっていましたが、来月8月から価格モデルの変更があるのであまり気にせず導入できるようになるので、ここも本腰を入れていく予定です。

さいごに

お約束ですが、Speeeの開発基盤ユニットでは、セキュリティと利便性を両立した社内環境や、開発環境を整備し、業務やプロダクト開発に注力できる基盤をつくっていくことをミッションとしています。

クラウドも、AWSだけでなく、GCP、Azureも利用しています。その分、考えることも多いですが、それぞれの強みや、違いを楽しむことができるのは楽しいと考えており、まだやることは多々で、ここからMake Historyしていきたいと考えています。

興味があれば、ぜひ @iogi までお声がけください!

www.wantedly.com