ルートユーザーって使っちゃダメなの？――クラウドを始める前に覚えておきたいセキュリティの基礎知識：親子の会話から学ぶクラウドセキュリティ（1）

親子の会話で出てくるような素朴な疑問点から、クラウド環境における情報セキュリティの技術を学習する連載。初回は、クラウドを始める前に覚えておきたいセキュリティの基礎知識について。

[青山桃子，日立ソリューションズ]

クラウドを使ってみたいなあ

おかあさん、僕、クラウドを使って、何か作ってみたいなあ。

あらいいわね、何を作るの？

　こんな親子の会話が、日常的に聞かれる日も近いのではないでしょうか。

　2020年から小学校でプログラミング教育が必修化となるなど、若年層向けのIT教育が盛んになっています。今や情報セキュリティはITにおいて切り離せない重要なものになりました。ITインフラの運用にも、アプリケーションの開発にも必要です。

　「デジタルネイティブ」とも呼ばれる現代の子どもたちは、日常的に躊躇（ちゅうちょ）なくITに触れています。紙とハサミで工作するのと同じように、マウスとキーボードでアプリケーションを作るような時代です。何ならスマホだけで作っているかもしれません。しかし、それらのセキュリティ対策は十分でしょうか？

　一方で、それを教えるべき大人、ビジネスや社会の基盤を支える社会人のセキュリティ知識はどうでしょうか？

　新型コロナウイルス感染症（COVID-19）拡大の影響によりテレワークの導入に本腰が入り、予定していた場合でも、そうでなかった場合でも、クラウドサービスへの移行が進んだことと思います。クラウドサービスの活用は、オンプレミスの場合とはさまざまな点で異なります。一見似たように思えることも多く、思わぬ落とし穴にはまることもあるのではないでしょうか。

　セキュリティも同様で、基本的にはクラウドもオンプレミスの場合と同じですが、細かいところでクラウド特有の注意点があります。

　ハードウェアからネットワークまで全てを自分が管理するオンプレミスと、SaaS、PaaSのように必要な部分だけを利用するクラウド。日々のセキュリティ対策や、いざインシデントが発生した場合の対応について、どのような差があるのでしょうか？

　本記事では、ITを扱う全ての人に身に付けてほしい情報セキュリティの知識を、クラウド環境における実践的な環境を題材に学習していきます。親子の会話で出てくるような素朴な疑問点を挙げることで、大人から子どもまで一緒に学習できればと思っています。また、親から子どもへの、もしくは情シスから従業員への、セキュリティ指導の参考になれば幸いです。

セキュリティって何を考えればいいの？

クラウドを使うならセキュリティのことを考えなきゃダメよ。

えっ、セキュリティって何？　何を考えればいいの？

大切な情報が勝手に見られたり、壊されたりしないように守ることよ。

大切な情報って何かなあ？　それに、誰が壊すの？　怖い……。

きちんと対策すれば怖くないよ。何が大切で、どうやって守るかを考えましょうね。

　セキュリティ対策を考える上で基本となる観点は「機密性」「完全性」「可用性」の3つです。常に念頭に置く必要があります。

	説明	例
機密性	許可された人／システムだけが情報にアクセスできるようにすること	個人情報にパスワードをかけて保存する
完全性	情報が許可なく改ざんされないようにすること	改ざんを検知するため、電子署名を付ける
可用性	必要なときに情報にアクセスし、使用できること	故障によるサービス停止を防ぐため、サーバを複数台用意して冗長化する

　まずは、保護対象とする情報資産を決定します。次に、それらの情報資産の機密性・完全性・可用性を脅かす脅威を特定します。そしてその脅威に対する現状の対策状況、脆弱（ぜいじゃく）性の有無、発生頻度、脅威が顕在化した場合の影響を見積もり、対策の内容やコスト、優先順位を決定します。

　また、ここで把握した情報資産は、継続的に資産管理と構成／変更管理を行っていくことが重要です。常に所持している資産を全て把握し、増減や変更があった際はそれを記録して最新の状態にしていく必要があります。

　それを行っておかないと、適切で継続的なセキュリティ対策が難しくなります。例えば、「メーカーから新しいセキュリティパッチが公開されたのに、適用すべき機器を把握していないので適用していなかった。その結果、サイバー攻撃の被害を受けてしまった」「設定ミスで、クラウドストレージ上のデータが全世界に公開されていた。その結果、情報漏えいが起きてしまった」といった状況になる危険をはらんでいるわけです。さらに、問題が起こった場合の調査、原因究明も難しくなり、対外的な信用を失う原因となり得ます。

クラウドって自分のサーバと何が違うの？

クラウドって自分のサーバと何が違うの？

クラウドはサービス提供形態によって、責任範囲や使える機能、扱えるデータが異なるのよ。自分のサーバ（オンプレミス）の場合は、基本的に『全部自分』になるのよ。

　セキュリティ対策を考える上で、顧客とベンダーの責任分界点を考えることはとても重要です。なぜなら、セキュリティが話題の中心となるのは、サービスが順調に動いている時ではなく、主に「サイバー攻撃を受けた」「情報が漏えいした」といった、問題が発生した時だからです。

　クラウドを利用する場合、ざっくりいうと、インフラはクラウドベンダー側、データは利用者側が管理することになっていることが多いと思います。

　インフラ部分のセキュリティ管理をクラウドベンダー側に任せられるのは大きなメリットです。クラウドベンダー全体で統制されているセキュリティレベルのインフラ管理を享受できます。そのため、利用者はインフラ管理に必要なノウハウを蓄積したり、インフラの運用に手を割いたりする必要がなくなります。

　クラウドサービスにはSaaS、PaaS、IaaSなど、いろいろなサービスの提供形態があります。具体的にどこまでをベンダー側の責任とし、どこから利用者側の責任とするかは、提供形態によって異なります。

	説明	例
SaaS（Software as a Service）	サービスベンダー側は既に構築されたソフトウェアを提供し、利用者側はソフトウェア上で扱うデータのみを管理する	「Gmail」「Microsoft 365」など
PaaS（Platform as a Service）	サービスベンダー側はOSやプログラムの実行環境などを提供し、利用者側は実行するプログラムを作成・管理する	「AWS Elastic Beanstalk」「Google App Engine」など
IaaS（Infrastructure as a Service）	サービスベンダー側は情報システムのインフラ部分を提供し、利用者側は使用するリソースやOSなどを選択し、管理する。HaaS（Hardware as a Service）という場合もある	AWS（Amazon Web Services）の「Amazon EC2」、Microsoft Azureの「Virtual Machines」など

　自分の責任範囲外のデータやログは、基本的に扱えないことが多いので、「ここのログは見たい」「ここのデータは自分で管理したい」などの要件がある場合は、サービス形態を選定する際に考慮する必要があります。

何となく、AWSが使いたいなあ

いろんなクラウドがあるみたいだけど、何となく、有名なAWSが使いたいなあ。

適切なアクセス制御ができるか、見たいログなどが見られるかどうかなどを事前に確認しておきましょうね。セキュリティ面では、クラウドベンダーの責任範囲でやっているところは利用者にはコントロールできないから、信頼できるクラウドサービスを選ぶのは大切よ。

　AWS、Azureなど、クラウドベンダーは数多くあります。機能やコストの観点で選択するのはもちろんですが、セキュリティ的にはどのような観点でベンダーを選択する必要があるのでしょうか？

　前項で責任範囲の話をしましたが、ベンダーを選定する際に、「責任の所在がどうなっているのか」を確認しておくことは重要です。AWSでは、以下の図のような責任共有モデルが提示され、責任が明確化されています。

AWS 責任共有モデルから引用

　セキュリティに関するホワイトペーパー「Introduction to AWS Security」もあります。

　こういった内容を確認し、「クラウドベンダーにインフラ部分のセキュリティを任せられるかどうか」「利用者の責任範囲とされている部分の情報資産を守るべき機能が備わっているかどうか」を判断するのがいいと思います。

　例えば、利用者管理の部分を守るのに使用できるサービスとして、AWSには下記のようなサービスがあります。詳細については、今後の本連載の中で触れる予定です。

• 「AWS CloudTrail」
  ユーザーアクティビティーとAPIの使用状況を追跡する（ログを取る）
• 「AWS Config」
  「AWS リソース」の設定を記録して評価（変更管理）する
• 「Amazon GuardDuty」
  悪意のある操作や不正な動作を継続的にモニタリングする
• 「VPC フローログ」
  Amazon Virtual Private Cloud （VPC）のネットワークインタフェースとの間で行き来するIPトラフィックに関する情報をキャプチャーする
• 「AWS WAF」（Web Application Firewall）
  一般的なWebの脆弱性からWebアプリケーションまたはAPIを保護する

ルートユーザーって使っちゃダメなの？

アカウントを作ったよ。早速、いろいろやってみよう。

待って。それはルートユーザーのアカウントよね。

そうだよ。

ルートユーザーはすごく強い権限を持っているから、悪用されると危険よ。多要素認証をかけて、普段は使わないようにしましょうね。

　AWSで最初にアカウントを作成すると、まずはルートユーザーのみ存在する状態になります。しかしルートユーザーには、請求情報などの機密情報も含む全てのリソースにアクセスする権限があります。ルートユーザーのアカウント情報は大切に守らなければなりません。

　日常的な管理業務に使用するアカウントは、つい管理がなおざりになりがちです。複数人でアカウントを共有したり、一時的に自分のID／パスワードを他人に教えたり、アクセスキーをメモしたファイルがデスクトップに置いてあったり……。ルートユーザー以外は雑に扱っていいのかというとそうではありませんが、少なくとも大切なルートユーザーはきちんと守るようにしましょう。

　AWSのアカウント管理は「AWS IAM」（Identity and Access Management）で行います。安全なアカウント管理を行うためのベストプラクティスがAWSから提供されているので、こちらの手順に従って管理すれば安心です。

　特に気を付けるポイントは下記です。

• ルートユーザーは使わない
• 多要素認証（MFA）を使う
• 権限はグループ（業務）に与え、必要最低限にする

　アクセス制御には「最小権限」の原則があり、「各アカウントには必要最低限の権限のみを持たせるべきである」といわれています。セキュリティ面では、主に「悪用やインシデント発生時の横展開を防ぐ」といった目的があります。

　ただ、最初から最小権限を正確に設定するのは難しいと思います。運用が安定するまでは権限を調整する必要があります。AWSでは、「AWS 管理ポリシー」として、一般的なユースケースでの権限のセットが提供されていますので、それを利用するのもお勧めです。

暗号化って何？

Webサービスを作ろうっと。ゲームのランキングを表示するんだあ。

すてきね。データを扱うときは、経路や媒体、データそのものが暗号化されているかを、普段から確認するようにね。

　暗号化は、情報の機密性のために必須となる考え方です。特にクラウドの環境では、インフラハードウェアを自分で管理できないことから、機密データの取り扱いについて不安に思う人は多いのではないでしょうか？

　暗号化には、考えるべきポイントとして、「個々のデータの暗号化」「媒体の暗号化」「経路の暗号化」の3つがあります。

　個々のデータの暗号化は、各自がzipファイルにパスワードをかけて保存するようなイメージです。また情報システムにおいて、「データベースにデータを保存する際、特に重要な情報（パスワードなど）には暗号化を行う」といった対策が考えられます。AWSの場合、ストレージ（「Amazon S3」）にデータを保存する際に「AWS KMS」（Key Management Service）の鍵を用いてデータを暗号化する方法などがあります。暗号化処理は、クライアント側で行う方法とサーバ側で行う方法があります。

　媒体の暗号化は、HDDやUSBドライブなど保存する媒体そのものを暗号化する方法です。クラウドの場合、データの保存領域であるボリュームを暗号化することで同様の効果が得られます。AWSの場合、Amazon EC2のボリュームは「Amazon EBS 暗号化」で保護することができます。

　経路の暗号化は、Webサービスの場合、SSL/TLSを使用したHTTPS通信が一般的です。HTTPS通信では、サーバの証明書を使用して暗号化を行うため、サーバの真正性を確認することもできます。経路が暗号化されていない通信は、傍受や改ざんの被害に遭う可能性があります。ネットショップなどで個人情報やカード情報などを送るときに経路が暗号化されていないと不安ですよね。昔はそういった機微な情報を送るときだけ暗号化することが多かったのですが、今は信頼性の観点からWebサイト全体がHTTPS通信に対応していることが望ましいとされています。AWSの場合、「AWS Certificate Manager」（ACM）でHTTPS通信のための証明書を発行することができます。

　さらにクラウドの場合、管理をリモートで行うことになるので、管理アクセスについても経路の暗号化に注意しなければなりません。詳細については、今後の本連載の中で触れる予定です。

考えなきゃいけないことが多いんだなあ！

そうね、一緒に勉強していきましょうね。