コラム

はじめに

こんにちは、クラウドCoEの熊谷です。

以前、お客様から以下のような相談を受けました。
「インターネットに公開しない社内システムをクラウドで構築する場合でもhttpsで接続できた方が良い？」
「もしhttps通信が必要なら、インターネットに公開しないプライベートなシステムだし、AWSで構築するからAWS Private CAを立ててプライベートなサーバ証明書を作らないといけないと思っている」

今回は、この2点についてお話したいと思います。

※今回はオンプレミスでまだPrivate CAを立てたことがないお客様からの問い合わせでした

結論

• 社員しかアクセスしない社内システムであっても、httpsで接続することが望ましいです
• プライベート証明書の方がセキュアですが、コスト観点でパブリック証明書を利用するという選択も出来ます

質問1. 社内システムも、転送データを暗号化した方が良い？

責任共有モデルにおけるデータ暗号化の定義

クラウドサービスプロバイダ（CSP）が提唱する責任共有モデルでは、システムのコンポーネントごとに、セキュリティや運用上の責任をCSPとサービスを利用するユーザのどちらが負うべきか定義されています。
このなかで、データの暗号化についてはユーザが責任を持つ必要があります。

参考：責任共有モデル © 2023, Amazon Web Services

この責任共有モデル上では、ユーザは自身のデータに関して完全な責任を持っています。
これは、データの作成、アップロード、保存、暗号化、バックアップ、復元などの処理をユーザが実施する責任があるということです。

AWSは、ユーザがAWSサービスを使用してデータを保護するためのセキュリティツールやサービスを提供しますが、それらのツールやサービスを使って実際にデータを暗号化するかどうか検討し、実施するのはユーザです。

データの通信時に暗号化をしないと、end-to-endの通信データが平文で流れてしまいます。
社員だけがアクセスできるシステムなので、社員が平文を見ることができても問題ないだろうと思われるかもしれません。
しかし現在は内部不正・内部犯行による情報漏洩が増加しているため、この考え方は危険です。

また通信時にデータを暗号化をしない場合、AWS等のCSPがend-to-endの平文の通信データの内容を傍受することができる状態になります。

当然ですが、AWSはユーザのデータを傍受することはないと明言しており、その点について第三者機関からの監査を受けて証明しているものの（※1）、データの管理責任がユーザにある以上、データは暗号化されるべきだと考えています。

また米国議会が海外のデータの合法的使用を明確化する法案 (CLOUD 法) を可決した際、AWSではブログにて、「お客様がコンテンツをさらに厳重に保護するために使用できる高度な暗号化やキー管理のサービスを提供します。」と触れています。

引用:AWS と CLOUD 法 | © 2023, Amazon Web Services, Inc

米国からのデータ開示請求という文脈においても、ユーザがデータを厳重に守るために暗号化が推奨されていることがわかります。
CSP内部からの不正アクセスと他国政府からのデータ開示請求は一例でしたが、情報漏洩した際のリスクを最小限にする為にも、顧客が操作権限を持つ暗号鍵を用いてデータを暗号化することが大切です。

※1

引用：AWS Security and Risk Management Forum 2023 G-1-1 お客様が機密情報をAWSに展開できた理由
※上記のセミナーのオンライン配信は既に終了しています

AWS Well-Architected Frameworkにおける推奨

AWSでは、システム設計や運用に関する大局的な考え方とベストプラクティスの集大成としてAWS Well-Architected Frameworkを公開しており、「6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性)」に分けて設計思想を紹介しています。
このWell-Architected Frameworkのセキュリティの章のなかでも、「すべてのデータは、安全な TLS プロトコルと暗号スイートを使用して伝送中に暗号化する必要があります。」と書かれています。

参考：SEC09-BP02 伝送中に暗号化を適用する | © 2023, Amazon Web Services

このことから、社員だけがアクセス可能な社内システムであっても、通信時に証明書を使用した暗号化を行うことが望ましいと言えます。

質問2. 内部向けのシステムだから、プライベート証明書を作らないといけない？

どのようにして暗号化通信を実現するべきか、AWSサービスを用いた実現方法について紹介します。

サーバ証明書の役割

SSL/TLSサーバ証明書には、2つの役割があります。

1. Webサーバおよびクライアント間の転送データの暗号化
2. Webサイト等のシステムの正当性証明（デジタル証明）

今回の相談のポイントとなるのは、1番目の役割である転送データの暗号化です。

2番目の役割であるWebサイト等のシステムの正当性証明（デジタル証明）について少し解説をしますと、Webサイトを運営する企業・組織の存在証明を認証局が行うことを指します。
証明書の認証レベルには、DV（Domain Validation）証明書・OV（Organization Validation）証明書・EV（Extended Validation）証明書の3つがあります。

※概要欄の説明は『AWSではじめるクラウドセキュリティ』（松本 照吾、桐谷 彰一、畠中 亮、前田 駿介. 株式会社テッキーメディア）のp.140から引用しています

たとえば、こちらのブログのドメイン名はcloud.bigtreetc.comですが、もしもbigtree.comというドメインが他に存在していた場合（紛らわしい！）、どちらが弊社BTCのサイトなのか、はたまたどちらも弊社のサイトなのか、URLから判断することは難しいかもしれません。

OV証明書・EV証明書であれば、サイトの運営組織についての情報が証明書から確認できます。
※以下ではデジタル庁のホームページで利用されている証明書を使って確認

パブリック証明書とプライベート証明書

SSL/TLSサーバ証明書には、パブリック証明書とプライベート証明書の2種類があります。

証明書を発行したり、失効させたりする組織のことを認証局(CA)と言い、公的に証明書の正当性を証明する機関を、パブリック認証局と言います。

一方、プライベート認証局で発行する証明書をプライベート証明書と言います。プライベート認証局は、個人や企業が運用することが可能であり、オープンソースのソフトウェアであるOpenSSLやOpenXPKIを使って、個人でも簡単に構築することができます。証明書の発行には費用がかからないものの、認証局を運用するためにはサーバのランニングコストが発生することに注意が必要です。

認証局についてわかりやすくまとめてくださっている記事をこちらに紹介させていただきます。
認証局の役割とは？｜電子署名の仕組みと種類を比較．HR NOTE 編集部．

AWS Certificate Managerとは

AWSにはSSL/TLSサーバ証明書を発行・管理するサービスとしてAWS Certificate Manager（ACM）があります。

ACMで発行したSSL/TLSサーバ証明書は、ELBやCloudFront、API Gateway等の他のAWSサービスに配置することが可能です。
ACMで作成した証明書は、AWSが証明書の更新や鍵の管理を行います。

ACMではDV証明書の発行が可能で、OV・EV証明書を発行することはできません。

またAWSのPrivate CAを使うことで、プライベート認証局を作成することができます。

インターネットに公開しない社内システム用のELBにもパブリック証明書を導入することができる

ACMのFAQにも記載がありますが、インターネットに公開しない社内システム用に作成したInternalなELBにもパブリック証明書を導入することができます。
なので「内部向けのシステムだから、プライベート証明書を作らないといけない」わけではありません。

参考：AWS Certificate Manager のよくある質問 | © 2023, Amazon Web Services, Inc

プライベート証明書を使うメリット

ACMのFAQには、以下のような追記があります。
「しかしAWSプライベートCAでプライベート証明書を発行すると、ACMは検証なしでこれを更新できます。」
これはパブリック証明書の有効期限は13か月(395日)で、更新時にドメイン検証が必要になることを指します。
一方でAWSのPrivate CAを使用して証明書を直接発行する場合は、任意の有効期間を選択することができます。

上記のメリットに加え、AWSのPrivate CAをInternalなシステムで利用する場合、システムを利用する端末にプライベート証明書を配布する必要が生じるため、どの端末がシステムを利用するかを厳密に制御できます。（★）

その他、パブリック証明書・プライベート証明書を使う場合のポイントを、ACMを使う場合とそうでない場合に分けてまとめた表がこちらです。

パブリック証明書の表

プライベート証明書の表

※2 プロバイダー指定の方法で検証します
参考：ドメイン名の利用権確認（DCV）方式．digicert Documentation
参考：ドメイン名所有者・使用権の確認について．GlobalSign by GMO サポートサイト

※3 デフォルトでは1年。参考：プライベート CA ライフサイクルの管理 | © 2023, Amazon Web Services, Inc

※4 参考：ACM への証明書更新権限の割り当て | © 2023, Amazon Web Services, Inc

※5 参考：AWS Private CA Pricing | © 2023, Amazon Web Services, Inc

※6 トラストストアとは証明書を管理するDBのデータベースのこと
Windowsでは「Windowsキー + R」キーを押して、実行ダイアログボックスを開き、「certmgr.msc」と入力し、Enterキーを押し、証明書マネージャーが表示されたら、左側のパネルで「信頼されたルート証明機関」または「信頼されたルート証明機関ストア」を展開すると、ルート証明書が表示される。

AWS Private CAは高い | ACMのパブリック証明書は無料

AWS Private CAを利用する際のデメリットとして、コストが挙げられます。AWS Private CAの利用料金は高額であり、一つのCAにつき月額400ドルの料金がかかります。

一方、証明書についてインターネットで検索すると、一般的に「パブリック証明書の方がプライベート証明書に比べて高い」という言葉がしばしば見られます。

確かに、DV証明書ではなく、より認証レベルが高いOV証明書やEV証明書を購入する場合は、DigiCertやGlobalSign等のプロバイダーから数万円～十数万円する証明書を購入する必要があります。

しかし、SSL/TLS通信を安全に行うための最低限のセキュリティ対策としてDV証明書を導入したいケースにおいては、ACMで提供されるパブリック証明書を無料で発行できますし、証明書を管理するためのサーバのランニングコストも発生しません。

ACMは、今回のケースのようにSSL/TLS通信を手軽に実現するには有用なサービスです。

インターネットに公開しない社内システムにパブリック証明書を利用する注意点

ただ、「社内システムにもパブリック証明書をどんどん使おう！」と言いたいわけではありません。
社内システムにパブリック証明書を利用するデメリットについても触れておきます。

プライベート証明書を利用する場合、システムを利用する端末にプライベート証明書を配布するという運用作業が発生しますが、パブリック証明書はChromeやFirefoxなど主要なブラウザに既にルート証明書が配布されていますので、そのような運用が不要です。
裏を返せば、システムを利用する端末を、SSL/TLS証明書では制御できないことになります。

その他にも、パブリック証明書を利用する場合の注意点として、以下2つが挙げられます。

1. パブリック証明書を利用するために、誰でもアクセスできるパブリックDNSのネームサーバでドメインを管理することになるため、誰でも名前解決できることを認識しておこう
2. ホスト名は漏洩するかもしれないので、ホスト名からサービスが推測されないよう、ホスト名はテキトーな文字列にしよう

インターネットに公開しない社内システムにパブリック証明書を使う場合、該当システムのドメインを、インターネットを通じて誰でも自由に利用できるパブリックDNSサーバで管理することになります。
つまり、万が一ホスト名が漏洩した場合、その社内システムの名前解決を外部の第三者が実施できる状態になってしまうことを指します。

ただし名前解決の結果応答されるのは社内システムのPrivate IPアドレスです。
隠すことができる情報は多いに越したことはありませんが、Private IPアドレスが漏洩した=外部から不正アクセスを受けることにはなりません。
（Private IPアドレスが知られて不正アクセスを受けることがあるとすれば、それはファイアウォールが突破され、社内のネットワークに攻撃者からの侵入を許していることになりますので、社内システムにパブリックDNSを使う/使わないの話とは別次元の問題です。）

一方、パブリックDNSサーバで管理するホスト名が漏洩した際のリスクとして、ホスト名からシステムの特性やサービスが推測されるという点が挙げられます。
外部に漏れる情報は少なければ少ないほど良いので、利用するホスト名についてはサービスが推測されにくいものを設定しましょう。

おわりに

以上、「社内システムにおいても通信時暗号化を取り入れた方が良いか」、「社内システムにプライベート証明書、パブリック証明書を使うメリット・デメリット」について記載しました。
この記事が、セキュリティとコストのトレードオフを考慮する際の一助となれば幸いです。