「セキュリティ面から考えるAWSの始め方」というタイトルでClassmethod Showcase 2022に登壇しました #cm_showcase

「Classmethod Showcase 2022 クラウドの歩き方」にて登壇した内容の解説です。AWSのセキュリティ怖くないよ！

#イベントレポート

#AWS

#セキュリティ

臼田佳祐

2022.10.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、AWSのセキュリティ対策してますか？(挨拶

今回は弊社の事例紹介がメインのイベントClassmethod Showcase 2022 クラウドの歩き方に登壇しましたので、その解説をします。

資料

解説

今回のセッションテーマは「セキュリティ的に安心してAWSを利用する」です。

安心とはなにか、というところからフォーカスして話していきます。

長い前説

いきなり質問1: 「AWSのセキュリティに不安がありますか？」

まずこの質問について考えてみましょう。

不安がある方は、実際にどこが不安でしょうか？

ここではいくつか参考の例を出します。もちろんこれ以外にもそれぞれあると思っていますが。

そもそもの例
- クラウド利用時の情報漏えい事故を耳にした
- インターネットは危険
- データを持ち出したくない
具体的な例
- 正しい設定がわからない
- ベストプラクティス通りできているかわからない
- もしかしたら不正利用されているかも

なんとなく不安、という気持ちではなく具体的に考えていく必要がありますね。質問に対するアンサーなどは一旦置いておいて次の質問にいきます。

いきなり質問2: 「みなさんの会社の機密情報は「今」安全ですか？」

大事なところは「今」安全であるかというところですね。

みなさんはどんな要素からこれを確認するでしょうか？例えば以下のような詳細な質問があると検討できると思います。

そもそも機密情報はなんですか？
どこに保存されていますか？
誰がアクセスしていい情報ですか？
実際誰がアクセスしていますか？
保存場所の設定は意図したとおりになっていますか？
今正常に利用できますか？
誰が責任者ですか？

つまり、安全であることを確認するためには、細かく現状を把握する必要があります。例えば以下の要素について把握する必要があります。

情報分類の定義
データとエンティティの識別
認証認可
モニタリング
証跡管理
責任範囲の定義

これらをきちんと把握し、安全であることを説明できて、ようやく安心できます。

つまり、AWSのセキュリティについて不安があるということは、AWSのセキュリティについて知らない、あるいはすでに利用している場合は今AWSの環境がどうなっているか説明できないことから来ています。

一方で、AWSはこの説明がめちゃくちゃやりやすいです。AWSはセキュリティと親和性が高いんです。

例えば以下の要素があげられます。

AWSではAPIで各設定を行い、設定状況もAPIで確認可能(可視性がある)
API経由で変更されたらそれをすべて記録(監査可能である)
すべてのAPIアクションを細かく制御でき、禁止したアクションの実行も検知できる(制御可能である)

従来のオンプレミスのような環境では、あるいはこれらのセキュリティの要素が考慮されていない環境では、このような性質を備え、セキュリティの説明をすることが困難でした。

AWSを利用するだけで、この問題に解決策を得られます。

これらの要素を具体的な技術の側面にあてると、以下のようになります。

データ保存
- 絶対外部からアクセスできない設定が可能
- 設定が保持されていることの確認や変更防止・アラートが可能
ネットワークアクセス
- SSHポートがグローバルに開放されているか確認可能
- 不必要なポート開放の検知・自動修復が可能
管理アクセス制御
- 操作者の権限を1アクション単位で定義可能
- 作成した権限がポリシーを満たしているか自動チェック可能

リアルタイムにどのような状況になっているか確認でき、自動的に違反を検知できます。

他にも、下記の要素もあります。

API経由で定義された設定を正確に、繰り返し同じように展開可能(正確性・再現可能性がある)
定義通り素早く全環境に一括展開可能(自動化可能・俊敏性がある)
すべての設定を常に監視し違反をすべて洗い出すことが可能(全数チェック可能)

従来であれば実現できないスピードですべてのリソースを管理でき、全てを確認することができます。

こういった要素も、AWSはセキュリティと親和性が高いといえるものですね。

AWSのセキュリティを理解していけると、安心してAWSを利用できるようにしていけます。

ちなみに、今回のスコープではありませんが、AWSのセキュリティにまつわる要素は本当にたくさんあるので、技術的な幅広い内容は下記ブログを参照してください。

AWSとセキュリティの基本

では本題の話ですが、AWSの前にセキュリティ自体の基本の話から始めていきます。ちなみにこの話は大体上記の全部盛りブログでも取り扱っています。

ここでは、セキュリティ対策のためにまずやることとして以下の要素を説明します。

資産を洗い出す
脅威とリスクを分析する
責任を明確にする

セキュリティで守るもの

何を守るためにセキュリティ対策しますか？というところからです。何を守るかを理解しなければセキュリティ対策は始まりません。

例えば以下のような観点があります。

データ
- 機密情報
- 顧客データ
- 個人情報
- クレジットカード
- コンテンツ
利用者
- 個人情報
- 投稿したコンテンツ
会社
- 業務システム
- 会社自体
- 企業イメージ
- 従業員
- 資金

ではこれらの守りたいものはどこにあるのか？きちんと把握できていますか？例えば以下のようなものがあります。

サーバー
データベース
ストレージ
PC
物理的な紙

これらの守るものは資産です。大事なことは資産の把握です。以下のような観点を整理していきます。

どこにあるのか
誰が責任者か
誰が管理しているのか
誰がアクセスできるのか
今すぐに状態がわかるか

資産の洗い出しをして・管理していきます。

脅威とリスクを理解する

情報セキュリティで扱う脅威は以下のようなものがあります。

情報漏えい
金銭の搾取
サービス停止
改ざん
なりすまし
権限昇格

これらの脅威は外的なもので基本的にコントロールできません。(内部不正などの内的な脅威はある程度コントロール可能です。)一方、これらの脅威は脆弱性と合わさることでリスクが発生します。脆弱性はコントロール可能なので、これを減らしていくことがセキュリティ対策のアプローチの1つです。

そして資産の価値も掛け合わせてリスクの大きさが変わります。リスクに応じて対策を検討していきます。

具体的なリスクとして「サーバーのデータが漏洩する」ことを考えてみます。この根本対策はアクセス制御を徹底することが上げられます。一方で補助的な対策としてDLP製品の導入などがあります。対策の順序としては根本対策が先になります。アクセス制御がおろそかなのにDLPを入れても意味がありません。

このようにリスクも洗い出し、どのようなことをやっていくかを考えていく必要があります。

資産を洗い出し、リスクを洗い出し分析したら優先順位が見えてきます。

セキュリティの責任は誰にあるか？

A. 全員です。当たり前ですね。

セキュリティはすべてのものに組み込まれる当たり前の要素です。ブレーキのない車は欠陥品ですよね。

セキュリティ担当者は特にセキュリティに強い関わりを持つだけで、開発者・運用者・監査人・経営者など他の人がセキュリティの責任を持たないことはありません。つまり全員セキュリティ担当ですね。もちろん必要な人が必要な範囲取り組んでいけばいいです。

というわけでひとりでセキュリティ対策できるわけないですよね。みんなで取り組みます。

原則と既存の対策

取り組むためには基本の知識が必要です。

セキュリティの原則は以下のようなものがあります。これらを押さえながら対策します。

最小権限
多層防御
識別・認証・認可
システムの堅牢化
フェールセーフ
シンプルにする
職務の分離
Design for Failure
人は間違える

一方で、既存の仕組みを一新しなければ行けないかというとそんな事はありません。

根本は変わりませんから、原則に従った対応を既存の仕組みやリソースと組み合わせて活用できます。例えば以下のようなものは引き続き利用します。

IDシステム
情報の分類
情報セキュリティポリシー
情報システム部の役割

もちろん、古いものであれば現在の状況・クラウドの状況などに合わせて更新していきましょう。

ちなみに、このようなセキュリティの考え方を学ぶためのアプローチとして、私はIPAの情報処理安全確保支援士試験はバランスがいいと感じています。網羅的で原理原則と技術のバランスがいいですし、最新の情報も扱います。個人的にはこちらの教科書が試験を受けても受けなくても役に立ちます。私は試験に受かってからも繰り返し読んでいます。

AWSを使う意味

あと、AWSを利用する意味も理解しておく必要があります。AWSのメリットについて理解していますか？

例えば以下のサイトがわかりやすいです。

AWS のクラウドが選ばれる 10 の理由 | AWS

俊敏性や柔軟性、マネージドサービスを活用してビジネスロジックに集中できるなど、なぜクラウドなのか？という意味を理解する必要があります。

そして、AWSのセキュリティを考える上では責任共有モデルの概念が大事ですが、マネージドサービスは特にAWSがセキュリティの責任を持つ範囲が広いため、積極的にマネージドサービスを利用することで、ユーザーが行うセキュリティ対策を減らすことが可能です。

AWSプロジェクトの始め方

基本の話を押さえたところで、実際にAWSの始め方を考えていきます。

まずは1つのAWSプロジェクトを始める、という小さい単位からです。

始めるときに必要なことは、前述している基本を始めAWSも特性や使い方を理解しておくということです。AWSプロジェクトを始める担当者は、これを理解しなければいけません。

AWS上で発生する脅威

先程のセキュリティの基本の話の通り、AWSを利用するのであればAWS上で発生する脅威についても適切に理解する必要があります。主に以下が上げられます。

誤った情報の公開・アクセス許可
- AWSはローカルPCの環境や社内の検証環境ではない
- 簡単に外部に公開して迅速に展開できる基盤
- 権限不備で情報漏えいが起きたり
- 不正な攻撃者がアカウントを乗っ取ることも
資金の浪費
- 従量課金で安く使い始められるけど、適切に管理しないと請求がすごいことに

この脅威は「AWSが危ない」という話では無いんですね。もちろん適切に利用すれば、トータル的にオンプレミスよりセキュアな環境の実現は簡単に・費用対効果高く・スマートに実現できます。適切に脅威を把握して、取り組んでいくことが大切です。

AWS利用を始めるにあたり、まずは「AWS利用開始時に最低限おさえておきたい10のこと」をチェックしましょう。

もう少し踏み込めそうであれば、下記も参照してください。

アクセス制御

初めにやることを補足すると、まずはアクセス制御を徹底していくことが必要です。

AWSの操作はAPI経由で実施します。その中でAWSでは、2つの強力な機能が動いています。

1つはIAM(Identity and Access Management)です。きめ細やかなアクセスコントロールを実現します。

もう1つはCloudTraillによるAPI実行のロギングです。AWSのAPI操作をすべて記録できます。

これらによりAWS上の操作は厳格に制御されます。必ず全てのリクエストが検証され、記録されます。これが最初から整っている事自体がAWSを利用するメリットでもあります。

AWSのベストプラクティス

このようなAWSの機能をどのように活用していくか、AWSではWell-Architectedフレームワークとしてベストプラクティス集を公開しています。

6つの柱があり、その1つがセキュリティです。これらを押さえていく必要があります。

ただ、ドキュメント量も多いため最初は下記ブログから確認していくといいでしょう。

Well-Architectedフレームワークはスルメのようなもので、一度読めば終わりではなく、何度も読んで噛めば噛むほど味が出るので繰り返し読んで理解していくものです。

AWSの基本的なセキュリティを理解する

AWSのプロジェクトを進めるためはすべてのAWS利用者にAWSの基本的なセキュリティを理解して貰う必要があります。

「すべての利用者」とすると大変に感じられますが、そんなときに活用できるのがAWSが提供している無償のデジタルトレーニング(Eラーニング)です。以下2つはこの用途に最適なコースです。ぜひ活用してください。

Introduction to AWS Identity and Access Management (IAM) (Japanese) (日本語吹き替え版)
- 10分の簡単なIAMの概要
AWS Foundations: Securing Your AWS Cloud (Japanese) (日本語吹き替え版)
- 50分のAWSセキュリティの基本

このようなコンテンツはたくさんあり、下記から利用できますので活用しましょう。

なお、これを徹底できないとどうなるのか、も説明します。

1つの実例として、AWS上で非常によくある事故の1つを引用します。

ある開発者が権限の強い認証情報をコードに埋め込み、GitHubに公開してしまいました。その10分後、不正利用が始まりました。この事例は下記で詳しく説明され、対策も載っていますので合わせて参照してください。

便利に活用できるマネージドセキュリティサービスを利用する

AWSではセキュリティサービスでも便利なマネージドサービスが存在しています。最初から有効化すべきサービスのうち、特に大事な2つを紹介します。

AWS Security Hub
- AWS環境の設定をセキュリティチェックする
- 危険な設定に気づいて是正できる
Amazon GuardDuty
- AWS上のログから脅威を検知
- セキュリティの問題をいち早く発見して通知できる

どちらもポチッと有効化するだけですので、非常にお手軽です。

AWS Security Hubは有効化すると、以下のように直感的なスコアの表示が確認できます。これにより、今そのAWSアカウントがどれくらいセキュアなのかわかります。

さらにチェックして引っかかったものを自動修復するところまで、やろうと思えばできます。以下の記事で詳細をご確認ください。

Amazon GuardDutyは様々な脅威を検知してくれますが、タイプとしては大きく以下の3種類があります。

IAMタイプ
- 主に不正なログインや漏洩したクレデンシャルの利用など
EC2タイプ
- コインマイニングやマルウェアによる通信など
S3タイプ
- 不自然なバケット公開やTor経由のアクセスなど

それぞれの対応は専門的で大変そうに感じるかもしれませんが、対応についてもあまり構える必要はありません。大体の対応方法はAmazon GuardDutyのユーザーガイドに掲載されていて、いざというときに活用できます。

詳細な運用についてのナレッジは以下を参照してください。

こういったサービスの活用方法まで含めた、AWSを始めるときに必要なセキュリティを学習するには、下記も参照するといいでしょう。

クラウドに対応した組織の作り方

1つのプロジェクトでのAWSの始め方を押さえたところで、組織全体でクラウドに対応していく話に移ります。

AWSの全体管理の仕組みも利用しつつ、組織の形も変わっていく必要があります。

AWSの全体管理の仕組み

仕組みは色々あるので、なるべく自動化していく事が必要です。

AWSの利用が促進すれば、何十何百とAWS環境やリソースが生まれます。これらに対するガバナンスを効かせるには自動化は欠かせません。

ガバナンスを適用していく上で必要なセキュリティ方針として、何でも禁止するゲート型のセキュリティではなく、危険がないようにガードレールを整備してその中で自由にAWSを利用できるようにしていくと良いです。

このガードレールを実現するためにマルチアカウントを管理するAWS Organizationsを利用します。特にこの機能の持っているService Control Policy(SCP)は、以下のようなガードレールを敷くことができます。

特定リージョン使用禁止
CloudTrail無効化禁止
GuardDuty無効化禁止
S3バケット公開禁止
タグのないリソース作成禁止

これらのサンプルはこちらにあります。環境に応じて使い分けるといいでしょう。

このポリシーにより、利用者が設定を変更すべきでない感利用の設定値や機能を守り、ポリシーに反する操作を防止します。AWS Organizationsの詳細は下記もご確認ください。

他にも、IDを集約管理するAWS Identity Centerや、ガードレールを簡単に整備しAWSアカウントのセットアップを迅速にするAWS Control Towerなども利用していけます。

クラウドに最適化したCCoEを立ち上げる

クラウドを推進するためにCCoEを立ち上げる企業も多いです。CCoE(Cloud Center of Excellence)はクラウド推進の組織です。組織により形は様々で、バーチャル組織として部門横断で活動することもあれば、情シスからの派生やDX推進チームが担うこともあります。共通して言えるのはクラウドのスピードに合わせて変わっていく組織です。

大事な点としては、CCoEは様々な部門を巻き込む必要があります。AWSはただのインフラではありません。開発や経営層の声を混ぜながら推進するために多方面の協力が不可欠です。