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