こんにちは！TECH Street編集部です。
「クラウドの伝道師が語るセキュリティ～AWSで実現するセキュリティと導入事例～」イベントレポートをお届けします！
企業はもちろん、政府機関によるクラウド活用も広がっています。世の中的にも、自社システムをオンプレ環境からクラウド上に構築する企業が増えてきましたよね。その一方で、「セキュリティが気になる」という理由から、クラウド活用に消極的な企業もまだまだたくさんあるのも事実。
クラウドを活用している企業は、どのようなセキュリティ対策を打っているのか？そもそも、クラウドのセキュリティってどうなっているのか？知りたいですよね。
今回は、「AWS」を活用したセキュリティについて、“クラウドの伝道師”によるセミナーとユーザーの導入事例から学べるイベントを実施。
最初の登壇者は、“クラウドの伝道師”、AWSの亀田治伸さん！まずはセミナーの様子から紹介していきます。
セミナー（亀田治伸氏／アマゾン ウェブ サービス ジャパン株式会社）
AWSではサーバー、ネットワーク、ストレージ、データベースなどすべて、API経由で操作することができるというのが大きな特徴。
→オンプレミスではあり得なかった【可視性】を提供できるので、セキュリティ観点で選ぶ上で大きなメリットなるとのこと！
AWSのセキュリティに対する基本的な考え方
セキュリティとコンプライアンスはAWSとお客様の間で共有される責任（一般的に言う共有モデル）。
AWSが管理するインフラレイヤー、いわゆるデータセンターの中身で動いている諸々のインフラネットワーク、ハードウェアAWSの機能を提供するソフトウェアなどについては、AWSの責任範囲になるので我々が責任を持って管理します。
一方、お客様は従来どおりOSより上、あるいはOSを使わないAWSのサービスを使うのであれば、そのサービスの設定をどうするかについてはお客様が責任を持ってくださいね、という考え方。
ここからは、セキュリティを担保するAWSの4つのサービスを紹介。
脅威分析⇒Amazon GuardDuty
利用者専用のプライベートネットワークの中身に流れるログであったり、AWSのリソースに対する管理者画面上の操作やAPI経由の操作を機械学習の力を使いながら、「危ないもの」「もしかしたら危ないもの」「安全なもの」により分けるサービス。
脆弱性分析⇒Amazon Inspector
AWS上でOSを起動した際、OSはもちろん、利用者がインストールしているミドルウェアのバージョンを見て、業界標準共通脆弱性のデータベースと照らし合わせながらレポートを出しているサービス。
情報資産分析⇒Amazon Macie
例えば、Amazon S3というオブジェクトストレージにマイナンバーが入ったデータが暗号化されていない状態で保存されている、クレジットカード番号や電話番号が保存されている場合にパターンマッチングで抽出するサービス。
統合管理とリスク分析⇒AWS Security Hub
上記三つのサービスから上がってきたアラートをまとめて統合して管理。さらにAWSの他のサービスと連携させて設定を書き戻すことも可能。
これらのサービスは、クラウド特有のもので、オンプレ環境に比べて、これらの機能を設定が簡単というメリットがあるといいます。また、リスクに対するアプローチそのものが違うとも。
これらのサービスは、いわゆるリスクベースのアプローチ。つまりリスクが発生した後にアラートが上がってくると、当然それだけでは高いセキュリティ環境は作れない。だから、あらかじめ作ってはダメな環境は作らせないようにするというアプローチなんだとか。
AWSの場合、メインの管理者がストレージは必ず暗号化するという設定をしてしまえば、他の管理者は何をどうやっても、暗号化していないストレージを起動することができないような状態を作り出すことができる。
→起動されるIDは、すべてAWSという管理基盤に組み込まれているので、野良IDみたいなものを作り出すことができない。
結果として高いセキュリティを維持することができるというのがクラウドのメリット！
ITマネジメントとITガバナンス
続いて、ITマネジメントとITガバナンスの関係について。
ITガバナンスは、ビジネスニーズによって生まれてくる会社全体のITに対する方向付けを行います。ITマネジメントというのは、ガバナンス側から定義されたポリシーに従って構築するITシステムのセキュリティをどのように計画・構築・実行・モニタリングするかという実際の手法を管理します。
→ITガバナンスとITマネジメントは密接に動いてITのセキュリティを担保していく必要がある！
システムが社内にバラバラに点在すると、ITガバナンス側の人が一元管理はできないが、クラウドを使うとITマネジメント側もITガバナンスも同じインターフェースを使って管理できる。それによって意思決定のスピード感がかわるといいます。ユーザーの要望に応じて、アジャイル開発のようにアプリケーションの書き換えもスピーディに対応可能になるといいます。
また、AWSでは「必要なセキュリティ設計を先に実施するという考え方」を提唱。「Security by Design」という言葉で表現しているといいます。
別の業界的に言うと、ShiftLeftっていう言い方もされたりしますが、左側から設計⇒開発⇒テスト⇒本番環境と時系列でシステムが流れていく中で、同じことをするのであれば左側で対応すればするほど安く済むという話。
あらかじめ起動されているリソースが、多くのAPIと連携することが前提として開発されているので、“これらの機能をあらかじめもう少し欲しい”と開発環境でオンにしておくことはできるはず。必要がなくなれば、後から消したほうが良いというのが、『Security by Design』という考え方なんだとか。
アジリティとガバナンスの両立
続いて、アジリティとガバナンスの両立について、亀田さんはいくつかの観点からお話をいただきました。
ポリシー策定と有効化
オンプレの場合は、①環境のセットアップ→②セキュリティ専門家がコントロールを有効化→③基盤が稼働する流れですが、AWSはそれを逆にしようと考えています。
最初にアカウント全体のマスター設定として、コントロールを有効化。そこで許された範囲だけ環境をセットアップできるようになるので、その管理権限を開発部隊のインフラ部隊に引き渡すだけで良いということが実現できます。
プロビジョニング
コントロールが有効化されたAWSのアカウントの設定は、マスター管理者がまず行います。そうすると現場側は許可された環境だけを起動することができるので、その範囲の中で自由に作業することができるように。
別のツールを開発して、リリースのたびに管理者におうかがいを立てる回数が少なくなると同時に、ビジネス側のユーザーもBIツールなど、必要なデータだけを必要な部門に提供していくということも、同じ基盤の中で実現することができます。
オペレーション
すべてのITのリソースはAPI連携することが前提なので、リソースおよびその上で動くアプリケーションの監視はしやすくなります。ただAWS側でOSを起動した場合、OS起動状態は自動で取れますが、OSの中身についてはお客さんの許可がない限りタッチしないという大原則があるので、デフォルト状態ではOSの中身、つまりアプリケーションの中身は取れません。
その代わりAWSには、お客さんのアプリケーションの中身やOSの中身をチェックするエージェントをいくつか提供。そのエージェントがインストールされたOSしか起動できないというコントロールをあらかじめ有効化しておくことができます。これはオンプレではできないことです。
他にも、障害対応が自動化できたり、リソース効率も一元管理で可能です。こういう機能は、オンプレミスでは全社共通IT管理基盤みたいなものを作らなくては見れませんが、AWSでは容易にそれらを実現してくれるサービスが用意されているといいます。
おまけの話
最後に亀田さんが取り上げたのは、本題とは少し離れたリモートアクセスクラウドの話。
リモートアクセスは、データセンターに行って、コンソールで作業することができないので、踏み台どうする？ということを考える必要があります。当然、従来のSSHの踏み台サーバーというのは、鍵情報をクライアント側と共有するので、クライアント側で鍵情報を漏洩すると結構な大惨事が起きてしまいます。あるいは、SSHプロトコルを使う場合、クライアント側から踏台側に対してファイアウォールは立てないといけないですよね。
そこでクライアント側から踏み台にSSH通信に飛ばさないといけないので、受け側はいいとして出る側もファイアウォールを空けておかないといけないのですが、それが結構大変な作業になります。なぜならAWSの場合踏み台側のIPアドレスが可変になるので固定できないですよね。結構幅広にIPを空けておかないといけないという問題もあります。
それを解決してくれるのがSession Manager。これを活用するとインバウンドポートを開いたり、踏み台ホストを維持したり、SSHキーを管理したりすることなく、監査可能なインスタンスを安全に管理できるとのこと。
ユーザー事例①：Amazon Detectiveから始めるAWSセキュリティの話
ここからは、実際にAWSを活用している企業で、セキュリティ周りを担当しているエンジニアの方にご登壇いただき、実例をお話しいただくことに。まず1人目は、パーソルキャリア株式会社の高田洸介さん！「Amazon Detectiveから始めるAWSセキュリティの話」というテーマでお話しいただきました。
パーソルキャリアに入社して、AWSを活用したクラウド環境の整備や移行推進を担当。最近、グループ標準のAWS環境を刷新したのお話を聞かせていただきました！
具体的には、1つのアカウントに複数のグループ会社のシステムが相乗りする統合シングルアカウント構成からマルチアカウント構成に刷新。これによってグループ会社にも個別アカウントに対する一定のadmin権限が委譲されてある程度自由な開発ができるようになったとのこと。
グループ標準AWS環境の状況
パーソル内のAWSのの環境について、わかりやすい図で説明していただきました。
いくつかのコアカウントと個別アカウントからなるマルチアカウント構成となっており、
・親会社であるパーソルホールディングスが統合的に管理
・個社であるパーソルキャリアは個別アカウントを利用して運用
この結果困りごとが発生したとのこと。
困りごと①
・社内のセキュリティ申請に時間がかかって、アプリに開発に集中できない
・セキュリティ関連で困るようなことが多発して、ホールディングスのCCoE組織がその対応に時間を取られる。
→自分たちでセキュリティを整備していこう！！と思いきや、、、
困りごと②
・個別アカウントでアラートが上がったとしても、それが直接個社にこない
＝ホールディングスのCCoE組織からの連絡を待つしかない
この課題に対して、2つの方針を立てたといいます。
解決方針
①ホールディングス側で実装しているところ以外のセキュリティ機能をどんどん補っていく
②ホールディングス側でセキュリティ機能も充実させていくという方針になった場合には、キャリア側で準備したセキュリティ機能もホールディングス側に委譲できるような用意をしていく
→パーソルキャリアが持つAWSアカウントのセキュリティ状況を把握したい、セキュリティインシデントもひとまず検知できるようにしておきたい、この把握と検知をとりあえず短期的に1カ月で整えよう！！
そこで、注目したのがAmazon Detective。30日の無料お試し期間があり、コストも実際に見積もりが可能。マルチアカウントにも対応しているため採用に至ったのだとか。
目標：AmazonDetectiveを利用して、セキュリティインシデント検知ができる状態。
調査
Amazon Detectiveに絞ったことで、わずか二日という短い時間で完了
設計
Amazon Detective自体に設定値がないので、ほとんどアカウント設計とかデプロイ設計の設計で済んだ
構築
AWSがマルチアカウントで構築できるスクリプトを流用できるので、今回でいうと80アカウント×全リージョンという規模感だったにもかかわらずスピーディに構築ができた
完成形
パーソルキャリア用のセキュリティアカウントをひとつ新たに作成。GuardDutyのアラートも全社で展開。
使用しているコミュニケーションツールであるTeamsに通知するフローを追加したのだとか。
Amazon Detectiveの設定を個別アカウントごとにしたので、パーソルキャリアのAWSアカウント約80個のセキュリティ情報を把握することができるようになり、各アカウントごとの状況を可視化できるようになったといいます。
Amazon Detectiveは導入ハードルが低く、スピーディに導入できた。また、UIが直感的でわかりやすく、学習コストも低いという印象を受けましたと語っていました♪
ユーザー事例②：自分たちで守るAWSセキュリティ対策事例
続いて登壇したのは、株式会社ベイシアの加藤雅之さん。ベイシアといえば、スーパーマーケットですが、おなじみのホームセンター「カインズ」や「ワークマン」を含む、流通グループの大手ですね。テーマは「自分たちで守るAWSセキュリティ対策事例」ということでご登壇内容を少しだけ公開します！
セキュリティ対策を実施するうえで大切なこと
①とにかくルールを決める
・CCoEを作る
・ルールで大切なのは原則、野良のAWSアカウントを作らせないこと
→CCoEは、部門を超えた話になるので、現場メンバーだけではなく部長以上の役職者にもお願いしたほうが良い◎
ベストプラクティスを鵜呑みにせず、ネットワークの方、オンプレの方、クラウド専任部隊などが集まって話をしてルールを決めていくことが大切とのこと。
②S3はSCPで外部公開をさせないこと
2大セキュリティインシデントは、S3のパブリック公開とIAMクレデンシャルの事故。
・外部への通信はすべてプロキシ経由という仕組みにする
・IAMクレデンシャルを使わないようにAWS SSOを導入
・セキュリティハブの導入
お話いただいた内容の要約となりますが、こんな内容をお話いただきました♪
まとめ
「クラウドの伝道師が語るセキュリティ～AWSで実現するセキュリティと導入事例～」イベントはいかがでしたか？
クラウドの“伝道師”によるわかりやすいセミナーと、リアルな事例発表という組み合わせで、すっかりクラウドセキュリティの基本が理解できたような気がしました。
参加者コメント
この他にもこんなコメントを頂きました♪
・他社さんの現場レベルのお話が聞けて良かったです
・生々しさ！すばらしい！
・学生にでも理解できるように砕いていただいた内容でわかりやすかった。
・結構細かい部分の紹介や、おすすめの基本セキュリティサービスも知ることができた
運営＆登壇者集合写真
ご登壇いただいた亀田さん、高田さん、加藤さん、Mitzさんありがとうございました！
次のページでは当日のQ&Aを紹介いたします。
Q&A
亀田さんへのご質問
（Q1）OSの前にクラウド側でOSインストールへの監視判断もできるという事で、ある意味オンプレよりもクラウドの方がセキュリティが優れているという考え方もできるという事なのですか？（すみません、私初心者です）
→クラウドのほうがセキュリティというより監視性が優れていますね。
（Q2）AWSのセキュリティを学びたいのですが、オススメの教材等ありますか？
→AWSのセキュリティーであればいろんなホワイトペーパありますけど、AWS認定セキュリティーという資格試験があってそこから必要なホワイトペーパがダウンロードできます。
（Q3）nspectorはOSにより対応範囲が違うようです（Inspectorのユーザーガイドによると）。CVE以外にLinux系ではセキュリティベストプラクティスも対応していますが、Windows Severではセキュリティベストプラクティスは非対応です。古い2008でも対応していないので、Windows系は今後も対応しないと考えて良いでしょうか。そもそもセキュリティベストプラクティスは重要ではないのでしょうか？
→Windows系に関しては、新しいものであればある程度対応しているという認識でいたのですが、もし明確にこれが対応していないというのがあれば教えてもらえれば調べさせていただきます。
ただセキュリティベストプラクティス、特に各ベンダーが出しているものは順守したりしているので重要でないと思っていないとは思わないと思います。
高田さんへのご質問
（Q4）dodaは結構古くからあるシステムですか？いまの仕組み（AWS）に代わったのはいつ頃からですか？
→ご認識いただいている通り、dodaはシステムとしては歴史が深くなってきており、ちょうど去年からオンプレ→AWSへのリフト＆シフトを計画していて、現在はリフトの段階です。
（Q5）パーソルキャリアさん、セキュリティについて今後の一番重要なToBeはコレ！っていうのを聞いてみたい。
→パーソルキャリアが現在利用しているパーソルグループ標準AWS基盤についてはすでに親会社であるパーソルホールディングス社にCCoE組織やITセキュリティ組織があるため、そことの分掌、役割分担がきれいに合意されている状態が一つ重要かなと個人的に感じています。
例えば、あるセキュリティ共通機能についてはパーソルキャリア側で構築、運用するが、一定のセキュリティインシデントが発生した場合はスムーズにパーソルホールディングス社の必要な組織に必要な情報が連携されるなど。
（Q6）パーソルキャリアさん、いいですね。体制的に何人でやってますか？
→今回のAmazon Detectiveのプロジェクトはメンバー2人で実施していますが、現在私の所属しているチーム的には5人おり、AWSへの移行推進であったり、AWS基盤のプラットフォーム整備、改善など対応しております。
（Q8）Guard Duty単体では使えないんですか。DetectiveとSecurity Hubとの違いもよく分かりません。
→Guard Dutyは発見的統制のサービスで、もちろん単体で利用できる認識です。
ただ、今回のケースだとすでにパーソルホールディングス側のCCoE組織がGuard DutyのMasterアカウントを握っており、パーソルキャリア側では権限がなかったことや、現状のAWSアカウント郡が実際にどういう状況なのかを能動的に見たかったということもあり、Detectiveを採用しております。
Security HubとDetectiveの違いについては、DetectiveのBlackBeltの資料（https://d1.awsstatic.com/webinars/jp/pdf/services/20200715_AWSBlackBelt2020_AmazonDetective.pdf）のP8あたりのNISTのフレームワークに沿ってAWSのセキュリティサービスが紹介されているスライドが分かりやすいかなと思いますが、Security Hubは集約、可視化、検知の役割を持ったサービスである一方、Detectiveは調査の手助けをしてくれるサービスであり、Detectiveが収集・分析してくれたデータを能動的に見ていくことができます。
加藤さんへのご質問
（Q7）ルール決め、何を参考にしましたか？（セキュリティコンサルさんとかからの提案？それとも内製的に自分達で情報収集？）
→内製的に情報収集が多かったです。亀田さんの様なイベントや、今は色んな所に情報はあるので。ただ、大事なのは自分達で理解して検討する事です。
（Q8）どのAWSアカウントでも、インターネットへのアクセスは全て1つのGWからに統一していますか？
→複数AZで冗長化しているNATの関係上、出口は2つありますが、全てのVPC内からのインターネットはTGWで集約して1つです。
今回のご質問は以上となります！
また、次回はテレワーク応援イベント第3弾ということで【Slack活用】について学びます。
日頃からSlackを活用しているITエンジニアやIT推進担当の方など、ぜひご参加ください＾＾
▼イベント詳細・申し込みはこちら
Slack社の担当に聞く、Slack最大活用〈テレワーク応援第3弾〉
