押さえておきたいクラウドセキュリティ考慮事項
―クラウドへ舵を切る組織のために―

Share

5/25(月)、全国において緊急事態宣言が解除されました。政府から「新しい生活様式」への対応が求められる中、今後もテレワークとそれを支えるツールやサービスの利用・準備の一環として、より広範囲にクラウドの利用を検討する企業・組織が増えると考えられます。本記事では、クラウドのさらなる利用拡大が予想される状況下、セキュリティに関して考慮すべきポイントを解説します。


この2つの数字は、統合型クラウドコラボレーションツールのミーティング機能におけるアクティブユーザ数を示したものです。「1億」はGoogle G Suite「Google Meet」のアクティブユーザ、「7,500万」はMicrosoft 365「Teams」のアクティブユーザとなります(2020年4月時点)。現在、上記2つのツールをはじめとしたオンラインMTGツール全般が、この数か月で急激にユーザ数を伸ばしていることはニュースなどでご存じの方も多いでしょう。

足元で一気に加速するクラウド利用

新型コロナウイルスの感染拡大以降、テレワークのためのツールとしてオンラインミーティングを導入した企業・組織は多数に上ります。また、オンラインミーティング機能を皮切りに、ファイル共有、ドキュメント作成、メールなどの機能を追加で導入した、導入を検討しているといったケースも多いのではないでしょうか。単機能の各種サービスを組み合わせて利用されているケースもあるでしょう(例えば、Web会議システム、チャットツール、ファイル共有システム、仮想デスクトップの組み合わせなど)。

そして、新型コロナウイルスの感染拡大第一波終息後については、ご存じの通り、政府から「新しい生活様式」を取り入れ、実践していくことが求められています*3。「3密回避」は、緊急事態宣言解除後も1年以上、中には数年単位で必要との予測*4もあることから、今後も、テレワークとそれを支えるツールやサービスの利用・準備については、オフィス環境やPCを従業員向けに整える取り組みと並行した対応が必要となるでしょう。「新しい生活様式」への一策となる前述のコラボレーションツールなどを入口に広範囲でクラウドの利用を検討する企業・組織が増え、さらには「2025年の崖」問題、DX推進、経済状況の変動に対応できるスケーラブルなシステムへの移行の必要性といった既存の推進要因も相まって、クラウド化の勢いは当面の間続くと見込まれます(図1参照)。そこで、今後クラウドのさらなる利用拡大が予想される中、セキュリティに関して考慮すべきポイントを以下に解説します。

図1:クラウド利用の加速の背景


クラウドのセキュリティで押さえておくべき2つのポイント

1.パブリッククラウドサービスのセキュリティモデルは、利用者とクラウドサービスプロバイダ(以下CSP)双方で責任を共有・分担するモデルである

まず知っておきたいのは、「パブリッククラウドサービスを利用すれば、そのセキュリティ対策もCSPに任せられる」わけでは無い、という点です。クラウドでは、利用者とCSPの双方で責任を共有・分担することになり、責任の所在が切り替わる境界となる「責任分界点」は、SaaS、PaaSといったクラウドの提供形態によって異なってきます(図2参照)。このため、契約、運用にあたっては、採用したサービスのどこまでがCSP、どこからが自組織(=利用者)の責任となるのかを明確に把握することが求められます。なお、ユーザアクセスやデータの管理についてはいずれのサービス形態でも利用者の責任となることから、ユーザアクセスのログの取得や監査、提供されるユーザ認証がセキュリティ上十分な機能を有するかの確認は、必ず利用者側で対応する必要があります。

2:クラウドのセキュリティ共有モデル

※同形態のサービスでもCSPによって責任分界点の詳細や機能面が異なることがあります。

2.クラウドでも情報漏洩や不正アクセスは起こる

世間を日々賑わせている大規模な情報漏洩や不正アクセス。実は、クラウド上で起きているものが少なくありません(図3参照)。その多くは、「初期設定が”ユーザ認証不要”となっている一部のデータベースで設定を変更していなかった」ことが原因とされています。ほかには、「管理者のパスワードが容易に予測できるものだったことが原因で不正アクセスが発生した」ケース、「ユーザアクセスの監査が不十分だったために不正アクセスに気づかなかった」ケースなどが知られています。また、統合型コラボレーションツールの法人利用者に対する大規模なフィッシング攻撃も継続して確認されています。

1.でも触れたように、ユーザアクセスは、いずれのクラウド提供形態においても利用者側の責任となるため、設定の確認やユーザアクセスの監査・分析といった運用面での対応は極めて重要といえます。また、併用しているサービスがある場合は、その設定についても十分な確認・管理が必要です。

図3:クラウド上でのセキュリティ事故・事件


【参考情報】

クラウドコンピューティングにおけるセキュリティの代表的な脅威については、業界団体から右記のようなランキングも公表されています。採用サービスや利用状況により該当しない項目もあるかもしれませんが、動向として押さえておくことをお勧めします。

出典:CSAジャパン「クラウド重大セキュリティ脅威~11の悪質な脅威」
https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2019/10/top-threats-to-cloud-computing-egregious-eleven_J_20191031.pdf


クラウドのセキュリティ確保に向けて

では、企業や組織は何を手がかりにクラウド上のセキュリティを確保していけばよいのでしょうか。ここでは、主な具体策を3つご紹介します。

クラウドセキュリティ確保のポイント

1.CSP選択の指標を持って適切なCSPを選ぶ

現在、内閣府や経済産業省が中心となり「政府情報システムのためのセキュリティ評価制度(ISMAP)」の策定が進んでいます。その一環として、2020年秋以降(予定)、CSPは登録監査機関によるセキュリティ監査を受け、同評価制度の要求事項を満たすことが必須となる見込みです。自社・組織において、政府情報システムと同等のセキュリティが必要になるとは限りませんが、今後、このISMAPによるCSPの評価結果を、CSP選択の指標の1つとして活用できるようになる可能性があります。

2.クラウドを含むセキュリティにかかわる人材を育成・確保する

セキュリティにかかわる人材の育成・確保は、今日、多くの企業・組織で喫緊の課題となっています。クラウド化の推進にあたっては、契約条件やサービス提供条件の精査、実際の構築におけるセキュリティ要件設定、運用面での手順やエスカレーションのプロセスの設定など、多岐にわたる対応が必要になります。クラウドも対象に含めたセキュリティ人材の育成・確保を推進していくことは、「新しい生活様式」を見据えた今後の組織運営を支えるセキュリティ基盤の強化に大きく寄与するでしょう。

3.クラウドのセキュリティ設定を客観的基準により評価する

実際にクラウドサービスを利用し始めて以降は、自組織のクラウド環境の設定を客観的な方式で確認・評価することが欠かせません。そこで役立つのが、信頼できる第三者機関が提供するツールやリソースです。例えば、非営利の業界組織であるCenter for Internet Security(CIS®)が手掛ける「CISベンチマークテスト」は、ITシステムおよびデータをサイバー攻撃から守るためのセキュリティ設定基準として国際的に認知されています。このベンチマークテストの基準を満たすことにより、自組織のクラウド環境の健全性をグローバル水準で確認できます。また、同じく非営利の業界組織であるクラウドセキュリティアライアンス(CSA)では、日本支部によって和訳された各種ガイドラインを逐次提供しています。自組織の環境の安全性をより高めていく上で、こうしたツールやガイドラインの活用も重要なポイントになります。

なお、既存のシステムをクラウドへ移行する場合には、業務プロセスの見直しやシステム要件の再定義なども必要になります。オンプレミス環境とは異なる環境への移行となることから、当然、前例踏襲主義では対応できません。「新しい生活様式」への行動変容が求められ、オフィスから在宅勤務へという大きな流れが進む中、システムの刷新においても、従来にない考え方や技術を積極的に検討し、取り入れていく姿勢が求められています。

「危機はまたとない変革のチャンス」と言われます。今、コロナウイルスによって大きく加速されたクラウド化の波に乗り遅れては、そのチャンスを逃してしまうかもしれません。前向きな意思決定で、より強いシステムの実現に向けた取り組みを推進していきたいものです。

BBSecでは、2020年6月現在、クラウドセキュリティ診断サービスを実施しています。前述のCISベンチマークテストのほか、主要クラウド環境におけるベストプラクティスに基づく評価や、クラウド環境上でお客様が用意されているプラットフォームの診断(オプション)も可能です。ワンストップで幅広いサービスをご利用いただけます。

「withコロナ」フェーズ下の業務環境を支える各種セキュリティチェックリスト

新型コロナウイルス感染症拡大に伴い利用が急増しているG SuiteやMicrosoft 365については、セキュリティのチェックリストや推奨設定例が公開されていますので、以下にご紹介します。


G Suite
Googleからセキュリティチェックリストが提供されています。自社・組織の規模や要件を踏まえたセキュリティ対策の実装に役立ちます。
小規模事業者向け(~100人):https://support.google.com/a/answer/9211704
中・大規模事業者向け:https://support.google.com/a/answer/7587183?hl=ja

Microsoft 365
MicrosoftからMicrosoft 365 Business向けのセキュリティチェックリストが公開されています。
Microsoft 365 Business向けチェックリスト:https://docs.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/secure-your-business-data?view=o365-worldwide

米CISAからもMicrosoft Office 365のセキュリティに関する推奨策が公開されています。
米CISAによる推奨策:https://www.us-cert.gov/ncas/alerts/aa20-120a

また、日本ネットワークセキュリティ協会(JNSA)では緊急事態宣言解除後の「withコロナ」フェーズへの対応へ向けたセキュリティチェックリストを提供しています。
https://www.jnsa.org/telework_support/telework_security/index.html
同協会のWebサイトには、加盟各社から提供されているテレワーク支援プランを取りまとめたページもあり、「withコロナ」フェーズへ対応に向けた取り組みの検討に活用できます。
https://www.jnsa.org/telework_support/index.html


Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

<インタビュー>上野 宣 氏 / ScanNetSecurity 編集長【後編】

Share

脆弱性診断に携わる傍ら、セキュリティ人材の育成や情報配信、提言活動の中心的な役割を果たされてきたScanNetSecurity編集長 上野宣氏に、昨今セキュリティ事情を率直に語っていただいたインタビュー。後編をお届けする。

(聞き手:田澤 千絵/BBSec SS本部 セキュリティ情報サービス部 部長)

前編→


実はそこにあるリスク

━━ネットワーク脆弱性診断の場合は、暗号化周りの脆弱性が割と多く検出されます。攻撃で実際に狙われる可能性はどのくらいでしょうか。

上野:脆弱性の中では比較的対応に余裕が持てるタイプと言えます。しかし、長い目で見ると、暗号アルゴリズムの問題によって解読されるとか、中間者(Man-in-the-Middle)攻撃をされるといった危険は否めません。リプレイス等のタイミングで、アルゴリズムの見直しや最新プロトコルへの対応をタスクに入れた方がいいです。

━━例えば金融系の企業ですと、PCI DSS(Payment Card Industry Data Security Standard:クレジットカード業界のセキュリティ基準)に準拠しなければなりませんが、一般的にはコンプライアンス面で準拠必須な規定がありません。

上野:強制力があるものはないですね。OWASPもASVS(Application
Security Verification Standard:アプリケーションセキュリティ検証標準)を出してはいるのですが。

━━GDPR(General Data Protection Regulation:一般データ保護規則)も今はあまり話題に出ませんね。

上野:結局、国内でビジネスしている企業にはあまり関係ないとか、せいぜいサードパーティCookieの扱いに注意するくらいだということで。一時期より騒がれなくなりましたね。

━━日本で強制力がある法律と言ったら個人情報保護法くらいでしょうか。

上野:攻撃されたことに対して開発会社が訴えられたことがありましたね。2014年だと思いますが、開発会社がちゃんとセキュリティを担保しなかったという理由で負けて、損害賠償金を支払うことになった。

開発会社は、きちんとした倫理観を持って自分たちが良いと認めるものを納めることが必要です。自転車だったらちゃんと規格があるのに。国際団体がWebアプリケーションの品質保証みたいなものを決めてくれたらいいのですが。

━━Webアプリケーション開発を依頼する際、開発会社にセキュリティを担保してもらうにはどうしたらいいでしょう。

上野:お勧めは、私などが作ってOWASPのセキュリティ要件定義書ワーキンググループで出している
要件定義書
です。

依頼側は、内容がわからなくてもいいから、これをそのまま持って行って、「これを作れますか」「これが大事だと言われたが、説明してもらえますか」という問いに対して話ができる開発会社を選ぶ。そうでない開発会社はやめたほうがいい。依頼企業がこのドキュメントを使ってくれるようになるといいなと僕は思いますね。

「これを守ると高くなりますよ」っていいように言われるんですけどね。「高くなる」って誰が言い始めたんですかね。セキュアに作るか、作らないかであって、高い部品が要るわけでもないのに。

━━対応できる技術者が高いんですかね。

上野:高くはなるでしょうね。でも、そこぐらいでしょ。安い人にお願いした結果ハリボテが出てきたら、それはユーザが騙されていることになる。

━━実際にセキュリティ要件に即した開発になっているかの見極めはどうしたらいいでしょう。

上野:受け入れテストで脆弱性診断を実施するといいでしょう。欠陥住宅の事件があった時、住宅を鑑定する資格を持った人がクローズアップされましたよね。部材が入っているか、接着剤がどうか等を専門的に見てくれる人。受け入れテストはそういった観点で重要なんじゃないかと。普通にアプリケーションを何回も見たって、機能がちゃんと動いているくらいしか確認できないですよね。キッチンにコンロが三つあります、火がつきますくらいしか分からないのと一緒です。だから、ちゃんとプロの目で見極める必要があると思います。

━━ネットワークの場合はいかがですか。特に、オンプレミスでネットワーク環境を構築する際に社内ネットワークの診断をやる企業は……

上野:社内LANのリソースに対して実施する企業は、ほぼ皆無だと思います。で、サポートが切れたWindowsサーバがまだ動いていたりします。「イントラネットだから別にいいですよね」とよく言われます。それが脅威だと思われていないのが脅威かなと思います。

リスクの算出方法として、「脅威の大きさそのもの」ばかりでなく、「発生する確率」という要素もあるため、例えば、同じ脅威でもインターネット上より、内部ネットワークの方が発生確率は低い、ということになります。しかし、もう一つ別の要素として、機密性や可用性との兼ね合いである「資産の価値」を考えてみます。例えば、インターネットにある僕個人のブログと社内LANにある機密情報入りのサーバを比べたら、今度は当然、後者が守られるべきとなるでしょう。掛け算していくと、最終的に逆転することがあるはずです。

━━当社もよくお客様に、「うちのWebサイトは個人情報扱ってないから診断は必要ない」と言われます。

上野:重要な情報があるか否かという判断軸になりがちですが、実は攻撃者が欲しいものとして、そのサーバ自体の信頼度がある。そこを踏み台にすると便利、という観点。私も侵入するときに踏み台をよく使います。乗っ取られた結果、次に乗っ取られる先、次に攻撃される先が出てきます。自分たちのオフィスの中に攻撃者を招き入れた結果、自分たちが加害者となって攻撃が行われる。それは駄目ですよね。

━━絶対に守らなければならないものと、リスクを多少許容してもかまわないものの切り分けができていないケースが多いように思います。

上野:リスクアセスメントが必要ですね。まず、何の資産があるかを知ることじゃないでしょうか。物理的、電子的、無形物、色々あると思う。何を守らなきゃいけないかをまず洗い出す必要がある。

━━業務におけるセキュリティというのはどうでしょう。棚卸をするにしても、セキュリティを考慮しながら業務する企業は実際には少ないと思っています。重要情報をそれと認識していなかったり。

上野:そこは、教育をしなきゃいけないと思います。上場企業だと全社員が受けるインサイダー情報のトレーニングがありますね。何を言っちゃいけなくて、何を漏らしちゃいけないのか。「これ重要だよね」という感覚は人によって全然違うので、それは企業が見解として示さなくてはいけない。

━━従業員のセキュリティ教育はどれぐらいの頻度で十分だと思いますか。

上野:最初は結構頻繁にやるべきだと思います。というのは、セキュリティにいちいち気をつけていたらしんどいので、企業の文化として根付くまで浸透させなくてはいけないからです。それ以降は、年に1度とか、追加教育を思い出したようにやるとか。人はどんどん忘れていきますので。

どうなるリモートワークセキュリティ元年

━━セキュリティは自然災害によっても変わりますし、流行り廃りもあります。今後1~2年はどういったことが予想されるでしょう。

上野:やはりリモートワーク絡みのセキュリティ問題が噴出するんじゃないでしょうか。自分のPCから漏れる、会社に侵入される、リモートワークのツールがフィッシングに悪用される、とか。今年は「リモートワークセキュリティ元年」かもしれないですね。

━━リモートワークセキュリティ元年!いいですね、それ。APTはどうでしょう。これからも減ることはないのではないかと。

上野:信用しやすくなるという観点だと、個人のPCに侵入する手口として、その人と仲良くなった後、オンラインミーティング系のツールだと偽ってインストールさせるのがますます増えるでしょうね。例えば相手に、「うちの会社、このツールじゃなきゃ駄目なんだよ。今日これから会議だから、すぐ入れてくれない?」って言われたら、絶対インストールするでしょ。しかもユーザは気づいてないかもしれない。僕もペネトレーションテストで使う手です。

━━あと、今まで注目されていなかったシステムや環境が注目されるとか。例えば、Zoomは爆発的にユーザが増えましたよね。脆弱性がこれまで一切出てこなかったツールで、今後はうじゃうじゃ出てくる、というような。

上野:今まで誰も調べていなかったのに、急に流行ったツールの宿命だと思います。Zoomはニュースにも取り上げられましたが、逆にすごくセキュリティに前向きな会社という印象を抱いてます。バグバウンティのプログラムも始めた。相当自信がないとできないことです。Zoomはこの3ヶ月~半年ですごくセキュアになると思います。

━━SNSはどうですか。システム自体というより、攻撃の入り口として利用されるとか。

上野:こんな中、LinkedIn等を利用して転職を考える人もいると思います。SNS経由でどこかを装って送られてくるっていうのは、非常に多そうですね。僕にもよく「パスワード漏れましたよ」って来ています。「あなたのSNSを半年前から見ています」というようなのです(笑)。

━━従業員がバラバラな場所で仕事をしている今、企業としてどのようなサポートをするのが、セキュリティの維持につながるでしょうか。

上野:リモートワークでも何でも、必要な環境を企業が提供することが大事です。ユーザ任せではいつか破綻します。特にPCと、中に入っているソフトも管理できる状態にするのが大切。自宅のルータやネットワークの問題は、そこまで大きな脅威ではない。やはりコンピュータ自体が安全であることが一番だと思います。繰り返しになりますが、リモートワークは今後増えることはあっても絶対なくならないので、従業員分の予算をちゃんと確保していただきたいです。

ーENDー 前編はこちら


上野 宣 氏
株式会社トライコーダ代表取締役
ペネトレーションテストやサイバーセキュリティトレーニングなどを提供。OWASP Japan 代表、情報処理安全確保支援士集合講習講師、一般社団法人セキュリティ・キャンプ協議会GM、ScanNetSecurtity編集長などを務め、人材育成および啓蒙に尽力。『Webセキュリティ担当者のための脆弱性診断スタートガイド ? 上野宣が教える情報漏えいを防ぐ技術』、『HTTPの教科書』ほか著書多数。

田澤 千絵
株式会社ブロードバンドセキュリティ(BBSec)
セキュリティサービス本部 セキュリティ情報サービス部 部長
黎明期といわれる頃から20年以上にわたり情報セキュリティに従事。
大手企業向けセキュリティポリシー策定、セキュリティコンサルを経て、現在は脆弱性診断結果のレポーティングにおける品質管理を統括。
メジャーなセキュリティスキャンツールやガイドライン、スタンダード、マニュアル等のローカライズ実績も多数。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


<インタビュー>上野 宣 氏 / ScanNetSecurity 編集長【前編】

Share

長年、脆弱性診断に携わり、セキュリティ人材の育成や情報配信、提言活動における中心的な役割を果たされてきた上野宣氏。ScanNetSecurity編集長として様々な取材もされてきた同氏に、この度、弊社よりセキュリティ事情について気になるあれこれをざっくばらんにお聞きする機会を得た。

(聞き手:田澤 千絵/BBSec SS本部 セキュリティ情報サービス部 部長)

後編→


リモートワーク環境のセキュリティ対策よもやま

━━新型コロナウイルス対策のため、様々な企業が急に追い詰められ、全然準備もできてないままリモートワークに踏み切ったところも多いと思います。セキュリティ上の問題噴出や、実際に侵害されたというニュースも目にしますね。

上野:私がコンサルしている会社で、比較的すんなりリモートワークに移行できた会社があります。元々は一切リモートワークを許可しておらず、VPNもなかったにもかかわらず、です 。そこは、いわゆるゼロトラスト*5
を体現していて、開発も含めビジネスを全てクラウド上で行っています。そういう環境を2年くらいかけて作りました。結果、PCを自宅に持ち帰ってもVPNなしでそのまま仕事ができる感じです。ゼロトラスト的なネットワークがちゃんと作れれば全然問題なく移行できることが、今回はっきりしたと思いました。

でも、ほとんどの会社はそういうわけにいかず、おそらく全て会社のイントラネット上にある。例えばActive Directoryやファイルサーバ。デスクトップに色々なファイルや開発ツールがあったり。

━━では、ゼロトラストでなく従来型のネットワークの場合は、どうすれば安全にリモートワーク環境に移行できるでしょうか。

上野:やはりVPNでしょう。ただし、VPNサーバがだいぶ前に設定されたままだったり、プロトコルが古かったり、IDとパスワードを共有していて誰が接続したかわからなかったり、といった問題に注意しなければならない。それに、全社員が接続できるVPNサーバとなると、急には対応できない会社が多いと思います。

なので、AWS、Google等のクラウドを利用してVPNサーバを立て、そこを回線として接続するのがいいでしょう。結構安く、早くできると思います。

━━AWS利用の場合、責任分界点と言いますか、クラウドサービスベンダが担保してくれる部分と、ユーザが行わなくてはならないセキュリティ対策がありますよね。どう注意したらいいでしょうか。

上野:CISなど、公開されているベストプラクティスを参照していただくのがいいでしょう。ちまたに溢れている個人のブログを漁って調べるという手もありますが、ちゃんと知識を持ったセキュリティベンダにサポートしてもらうのが一番です。わからないのを自分たちで何とかするのではなく、会社の資産を守る大事なところですので、補正予算を組み会社をあげて緊急でやるべきです。

━━コロナウイルス対策で生産性が落ちている会社もある中、追加でセキュリティ費用を捻出するのは難しいと想像しますが……

上野:経営者がどう捉えるかですね。逆に、「オフィスいらないな」と考える経営者もいるわけで、その分リモートワーク環境に投資することもあると思うんです。今まで手間かけて机と椅子を用意していたのは何だったの、みたいな。このままコロナの問題がゼロになることはないでしょうから、いかに早く環境を整えるかが、ビジネスで勝つために重要ではないでしょうか。

━━先ほど上野さんがおっしゃったゼロトラストネットワークを実装する場合は、アクセス制御辺りが肝になりますか。

上野:ID管理をしっかりしなくてはいけません。ゼロトラストを体現するためにIDaaS(アイディーアース:Identity as a Service。ID管理をクラウドで実施するサービス)を導入することで、アカウント管理をユーザ任せにせず、組織が管理する。海外だと、CISOのような感じでIDを管理する専門の役職もあると聞いたことがあります。

━━従業員に対しては、どのような注意をしておけばいいでしょうか。

上野:パソコンは共有のものを使わない。ルータも最新のものを使う。人目につく公共の場では作業を行わない。あと、OSとアプリケーションのアップデート。昔から言われていることと同じです。
IPAが出している注意喚起
は、割と簡潔で分かりやすいですね。

━━自宅環境でのリモートワークにあたり、環境を全て用意できない会社もあります。会社支給のPCでなく、自宅のPCを使用する場合の注意点は?

上野:まず脅威として考えられるのは、マルウェア感染とか、攻撃者による遠隔操作とかですね。会社の重要情報をPCに置いてしまうと、盗まれる可能性が出てくる。さらに、会社にVPN接続するとか、会社の何らかのサービスにアクセスするとなると、そのIDやパスワードも盗られて中に侵入される危険性もある。

もちろん、会社支給のPCならそういった事態が起きないというわけではありませんが、可能性は低い。資産管理ツールが入っていて余計なアプリケーションがインストールできないといった、ある程度の対策できるはずですから。

━━あと、懸念されるのはフィッシング系でしょうか。コロナウイルスに便乗したメール詐欺が増えています。

上野:東日本大震災の時もそうでしたが、緊急事態があると、広く人々に関係のある事象が増える。例えば、コロナ対策で政府からの給付金をもらうために手続きがオンラインでできます、となると、「俺、関係あるな」となる。攻撃者は騙しやすいポイントをすかさず利用してきます。

対策としては、許可されていないアプリケーションをインストールしないようにするとか、すべて疑ってかかるよう教育するとか、でしょうね。

脆弱性診断ホンネトーク

━━上野さんご自身も、普段ペネトレーションテストや脆弱性診断を実施されていますが、当社のシステム脆弱性診断では、高リスク(当社基準)以上の脆弱性の検出が全診断件数の3割ほどにのぼります。この現状をどう思われますか。

上野:脆弱性診断には相当長いこと関わっていますが、「全く世の中改善しないな」と思っています。僕らのアプローチが間違っているんじゃないかと思うぐらい。毎回、同じような脆弱性が出るし。

ここ何年か、「興味がない人に、いかにセキュリティを届けるか」という僕のテーマがあるんですが、非常に難しい。だから、そういう人たちが意識しなくてもできるようにしなければいけない。例えば、Webアプリケーションでクロスサイトスクリプティングを直すのはプログラマではなく、フレームワークとかAPIを使うことで誰が作っても安全なものになるような環境にしていく。もちろん、セキュアコーディングというものが消えるわけじゃないが、たとえそれを知らなくても安全なものを作れる仕組みのほうが、僕は必要だと思っています。

あとはWAF(Web Application Firewall)も含めて、全方位で担保できるもの。どんなひどいプログラムを書いても大丈夫なように、プラットフォームとかフレームワークとかWAFとか、各レイヤでなんとかできるようにするのがいい。

━━1つの対策だけじゃ守りきれないですから、多層防御は重要ですね。怖いのはゼロデイの脆弱性が見つかった時じゃないですか?

上野:ゼロデイ攻撃がわかってからパッチが適用されるまでの間は、Webの場合はWAFで防御できる可能性もあります。セキュアコーディングでは対応できないかもしれないし、フレームワークのアップデートを待っていたら攻撃される恐れもあるので。

フレームワークやライブラリのバージョン管理も大切です。そのためのOWASP Dependency Checkというツールなどがあります。

━━バージョン管理が徹底されていない会社はとても多いです。環境によってはアップデートできないというお客様もいらっしゃり、そうなると多層防御で、WAFやIPS/IDS入れてください、となると思います。

上野:我々診断業界も変わらなきゃいけないかもしれないです。診断の結果、クロスサイトスクリプティングが出たことだけ言うのでなく、出ないようにするには業務をこう変えなくちゃいけないですよ、と。我々もクロスサイトスクリプティングを見つけるの、飽きたじゃないですか(笑)。

そもそも最低限クリアしてしかるべきセキュリティレベルがあって、その上で脆弱性診断を受けてほしい。他の業界でもそうじゃないですか。安全な車を作った上で衝突テストをやるからいいのであって、適当に作った車で衝突テストしたってバラバラになるに決まってるじゃないですか。安全基準どおりのフレームワークで作った上で、「絶対安全なはずだけど念のためテストしてほしい」となるのが、脆弱性診断の本来あるべき姿だと思います。

━━同じ組織内でポリシーが定まっていない場合もあります。例えば、グループ企業同士を診断したら、A社はセキュリティの堅牢なシステムなのに、同じグループ傘下のB社は穴だらけだった、というような。

上野:そもそも共通のルールやフレームワークがない組織が多い。でも、今後作るものについてだけでも対応していけば、5年後には良くなっているかもしれない。たとえ現状を変えるのは難しくても未来は変えられると思うので、そこは考えていただきたいですね。これを機に、リモートワークを適切に推進して、セキュリティ対策を「コストではなく投資だ」と言える会社が生き残っていくのではないでしょうか。

ー後編へ続くー


話し手 / 上野 宣 氏
株式会社トライコーダ代表取締役
ペネトレーションテストやサイバーセキュリティトレーニングなどを提供。OWASP Japan 代表、情報処理安全確保支援士集合講習講師、一般社団法人セキュリティ・キャンプ協議会GM、ScanNetSecurity編集長などを務め、人材育成および啓蒙に尽力。『Webセキュリティ担当者のための脆弱性診断スタートガイド - 上野宣が教える情報漏えいを防ぐ技術』、『HTTPの教科書』ほか著書多数。

聞き手 / 田澤 千絵
株式会社ブロードバンドセキュリティ(BBSec)
セキュリティサービス本部 セキュリティ情報サービス部 部長
黎明期といわれる頃から20年以上にわたり情報セキュリティに従事。
大手企業向けセキュリティポリシー策定、セキュリティコンサルを経て、現在は脆弱性診断結果のレポーティングにおける品質管理を統括。
メジャーなセキュリティスキャンツールやガイドライン、スタンダード、マニュアル等のローカライズ実績も多数。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

診断結果にみる情報セキュリティの現状
~2019年下半期 診断結果分析~

Share

SQAT® Security Report 2020年春夏号

BBSecの診断について

当社では、Webアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT、パブリッククラウド、ソースコード、標的型攻撃に対するリスク可視化等、様々な局面における診断サービスを提供することで、お客様のニーズにお応えしている。

当社の脆弱性診断サービスは、専門技術者による高精度の手動診断と独自開発のツールによる効率的な自動診断とを組み合わせ、検出された脆弱性に対するリスク評価について、右表のとおりレベル付けしている。お客様のシステム特性に応じた脆弱性の検出、リスクレベルの評価、個別具体的な解決策の提供が適切に行えるよう、高い頻度で診断パターンを更新し、診断品質の維持と向上に努めている。

2019年下半期診断結果

当社では、2019年7月から12月までの6カ月間に、14業種延べ537企業・団体、4808システムに対してシステム脆弱性診断を行った。情報セキュリティ対策に重きを置く企業・組織側の姿勢もあり、診断案件数は年々増加している。脆弱性の検出率は以下のとおりである。

脆弱性診断脆弱性検出率2019年下半期

診断の結果、Webアプリケーション診断では、脆弱性が検出されたシステムが全体の81.5%と、前年同期(2018年下半期)の84.9%に比べて微減しているものの、依然として高い割合である。ネットワーク診断においては、脆弱性検出率はシステム全体の47.8%であり、2017年下半期以降、減少傾向にあるが、およそ半数のシステムに何らかの脆弱性が検出されている。

検出された脆弱性のうち、早急な対処が必要な「高」レベル以上のリスクと評価された脆弱性は、Webアプリケーションでは26.9%、ネットワーク診断では30.4%検出されている。前年同期比(2018年下半期「高」レベル検出率:Webアプリケーション27.6%/ネットワーク診断 17.8%)でいうと、Webアプリケーションはほぼ横ばいだったが、ネットワークは12.6ポイント増えておりリスクレベルの高い脆弱性が増加傾向にある。当サイトでは、
「2019年下半期カテゴリ別脆弱性検出状況」
とし、当社診断で検出された脆弱性を各性質に応じてカテゴライズし、評価・分析をした結果をまとめた。以降、診断カテゴリごとに検出数が多かったものの中から、特筆すべきことに焦点を当ててリスクや対策を述べる。

Webアプリケーション診断結果

Webカテゴリ結果の31.4%を占める「システム情報・ポリシーに関する問題」のうち、最も検出数が多かったのは、「脆弱なバージョンのOS・アプリケーションの使用」である。脆弱なバージョンのOS、アプリケーションを使用している場合、既知の脆弱性の影響を受ける可能性がある。最新バージョンへのアップデートが望ましいが、システム環境における制約等の理由でバージョンアップができないのであれば、必要なセキュリティパッチがすべて適用されていることを確認すべきである。

次にWebカテゴリ結果の検出割合が多かったのは、19.7%を占める「セッション管理に関する問題」。最も検出されたのは、「不適切なセッションタイムアウト」であった。ログインセッションのタイムアウト値が適切に設定されていないと、長時間操作を行わずアイドル状態のままでもセッションが維持されることから、セッションハイジャック等の攻撃が成功する確率が高まるほか、サービス運用妨害(DoS)攻撃につながる可能性もある。セッションタイムアウトは、Webアプリケーションのデフォルト設定として一般的に採用されている30分が望ましいが、ユーザビリティを考慮してタイムアウト値を長くする場合は、追加のリスク緩和策を講じることが推奨される。

ネットワーク診断結果

NWカテゴリ結果の52.3%が「通信の安全性に関する問題」であった。なかでも、「推奨されない暗号化方式の受け入れ」(検出割合は右表を参照)の検出数がトップであり、第2位の「推奨されないSSL/TLS通信方式の使用」と比べて2倍以上の差がある。

サーバがブロック長64ビットのブロック暗号をサポートしている場合、誕生日攻撃(birthday attack)を介して長い期間暗号化されたセッションを復号・解読される「SWEET32」と呼ばれる攻撃の影響を受ける可能性がある。「NVD(National Vulnerability Database)」などに本脆弱性の影響を受ける製品は公表されており、ベンダからも正式な対策が公開されていて、ベンダ情報を参照のうえ対策することが望ましい。

SSL/TLS通信において、強度の低い暗号化方式(RC4、3DESなど)が許容されていると、既知の脆弱性を悪用した攻撃(平文回復攻撃など)により、攻撃者に暗号化されたデータが解読される危険性がある。また、強度が低いハッシュアルゴリズム(SHA-1など)が許容されていると、衝突攻撃に弱くなり証明書の偽造等が可能となる恐れがある。鍵長が128ビット未満の暗号方式については、総当り(Brute-Force)攻撃への耐性が低く、中間者(Man-in-the-Middle)攻撃などの標的になりうる。強度の低い暗号化方式やハッシュアルゴリズムは使用を停止し、SSL/TLSによる通信の保護には鍵長が128ビット以上の暗号化方式を実装するべきである。SSHプロトコルにおいても、攻撃者に暗号文を解読される恐れがあるため、脆弱な暗号化方式およびハッシュアルゴリズムを許容しないことが望まれる。


カテゴリ別の検出結果詳細についてはこちら

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

クラウド環境におけるセキュリティの重要性

Share

SQAT® 情報セキュリティ瓦版 2019年10月号

利便性+αで求められるセキュリティ意識

その利便性の高さからクラウドが広く普及しています。いまや既存システムのクラウド環境への移転、リニューアル化は時代の潮流といって良いでしょう。一方で、サーバ運用においてインシデントが発生してしまった場合、なりすましやDDoS攻撃などによって様々な面で大きな被害を受ける恐れがあります。現実にサーバ運用のトレンドになっているクラウド環境では、その利便性に潜む罠によって、近年いくつもインシデントが発生しています。クラウド環境を利用するために重要な「リスクの可視化」についてお伝えいたします。


アメリカ金融大手で1億人を超える情報漏洩

2019年7月、米金融大手Capital Oneは、外部の第三者から不正アクセスを受け、1億件を超える大規模な個人情報漏洩があったことを公表しました。*1 ただし、流出した個人情報(右記、表1参照)を悪用した事例は、9月時点で確認されていないとのことです。

今回のインシデントはAWS(Amazon Web Services)環境下で発生しましたが、そこで同社は以下の点を主張しています。

基盤システムへの侵害はない
●クラウド特有の脆弱性ではない
●対応の早さはクラウド利用の恩恵

 

 

SSRF攻撃の概要

 

インシデントから浮上した問題点

Capital Oneのシステム環境における問題点は、WAFの運用上の設定ミスにより、SSRF攻撃(図1参照)を検知できなかったこと、サーバ上のデータに対するアクセス制御が不十分だったこと、データ奪取に気づけるモニタリングを実施していなかったことが主に挙げられます。AWSはリスク軽減策としてツールを提供しており(上記、表2参照)、これを活用していれば、インシデントに繋がらなかった可能性も考えられます。

 

クラウド環境の利点と危険性

クラウドサービスは、高い利便性ゆえに増加を続けています。米Ciscoはホワイトペーパー*の中で、2016年には1年あたり6.0ゼタバイト 1) だったトラフィック量が、2021年には19.5ゼタバイトまで増加し、全データセンターのトラフィックに占めるクラウドデータセンターのトラフィック比率は、88%から95%へ増加すると予想しています。こうした増加の理由は、クラウド環境が自社設備内で情報システムを管理・運用するオンプレミス環境と比べて、コスト面、運用面での利点があるためと考えられます。一方で利点に対して危険性があることも理解しなければなりません。

1. 自社内にオンプレミス環境を用意する必要がない
 →外部委託することにより、他社環境に依存することになる
2. 仮想化されたリソースの配分自由度が高い
 →従量課金のため、使いすぎると高コストになる
3. 構成するソフトウェアの独自開発が不要
 →構成するソフトウェアがオープンソースのため、攻撃者に解析されやすい

一度攻撃を許してしまえば、情報漏洩、DDoS攻撃によって、莫大な費用損失が発生し、企業のビジネス破綻を招く可能性があります。クラウドサービスの利用には、利便性と引き換えにある攻撃の可能性にも目を向ける必要があります。そもそも、基本的にクラウド環境は公開ネットワークからアクセスが可能なため、セキュリティ設定の実施は必須なのです。

では、実際にどのようにセキュリティを強化していくのか。対策の一つとして各クラウドベンダが提供しているクラウド環境上のセキュリティ関連の汎用モジュールを利用することを推奨します。例えば、AWSの場合では、インターネットセキュリティの標準化団体であるCIS(Center for Internet Security)が公表している『CIS Amazon Web Service Foundations Benchmark』というガイドラインや、第三者による評価(当社では「AWSセキュリティ設定診断」として提供)を活用し、システム環境の設定状況を把握することが望ましいでしょう。

 

独自性カスタマイズのリスク

クラウド環境は各ベンダの提供している汎用モジュールが充実していますが、実際の提供サービスの機能と合致しないことがあり、その場合、独自のカスタマイズや実装が必要になります。前述のCapital Oneのインシデントでは、このカスタマイズこそがあだとなりました。実際の運用環境では、ポリシーや他との互換性を考慮して様々なカスタマイズが行われますが、その際に設定ミスが発生することで、セキュリティホールとなる可能性があることを認識し、十分に注意しなければなりません。また、カスタマイズされたモジュールそのものに問題がなかったとしても、汎用モジュールとの連携が原因で問題が発生することもあるでしょう。クラウド環境上でWeb サービスを提供する場合には、各種設定がベストプラクティス(最善策)に適合しているかを把握し、さらに第三者の目から見た診断によって分析を行い、リスクを可視化することが重要です。

 

クラウドの時代

今後、世の中はますます利便性の高いクラウドへと傾倒し、既存システムのクラウド環境への移転、リニューアル化がもはや時代の潮流となるでしょう。それゆえに、攻撃者の格好のターゲットとならないよう、隙を与えないための定期的な診断によるリスク把握は、クラウドを用いたビジネスにおいて必要不可欠なのです。

 

※SSRF攻撃(Server Side Request Forgery)
公開サーバに攻撃コマンドを送信することで、サーバ権限を利用し、非公開の内部サーバに攻撃が実行可能になる。
クラウド環境の内部サーバに対して、メタデータ取得APIを実行させ、ユーザの認証情報(ID・パスワード)を盗み取れる。


注:
1) 6.0ゼタバイト=6.0×1021

参考情報:
*https://www.cisco.com/c/en/us/solutions/collateral/service-provider/global-cloud-index-gci/white-paper-c11-738085.html


Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

<対談>縫田 光司 氏(東京大学大学院情報理工学系研究科数理情報学専攻 准教授)× 芦原聡介(BBSec)

Share

SQAT® Security Report 2019年9月号

量子コンピュータの実用化と耐量子暗号の標準化動向
~ 未来は遠く、それでいて近い ~

通信の安全性に特化した技術として普及している暗号化や認証技術。コンピュータの進化によって、そう遠くない未来には現在普及している暗号技術は破られてしまう可能性がある。このシナリオに抗うため、日夜研かれし頭脳を駆使して挑戦を続ける研究者たちがいる。その中のひとりである、東京大学の縫田 光司氏をお招きし、当社セキュリティサービス本部でアナリストを務める芦原聡介とさまざまな角度から暗号技術の可能性を語り合っていただいた。

※インタビュー内容、役職、所属は取材当時のものです。

量子暗号と耐量子暗号の違いについて

芦原:まずは対談の企画段階で、量子コンピュータの実用化の話題が候補に挙がり、そこから派生して米国政府の耐量子暗号の標準化動向などにも触れたい、となったのですが、社内で検討していくうちに「そもそも量子暗号と耐量子暗号を混同している方もいるのでは?」という疑問が生まれました。

縫田:たしかに、混同されることも多いです。単純に字面だけでいうと、日本語には“耐”が付いているだけ、英語でもQuantum cryptographyとPost – Quantum cryptographyでして、「“耐”“Post”が付いているほうが改良版」と捉えてしまう方も結構見受けられます。実際は全くの別物で、量子暗号というと量子コンピュータを使った暗号化技術を指すこともありますが、実際には量子鍵配送、つまり量子力学の原理を利用して暗号化に使用する秘密鍵を安全に相手に送り共有するための技術を指す場合が多いです。

芦原:そうですね。量子鍵配送に関しては、ITU-TでY.3800勧告として承認され、国際標準の骨格に日本の技術が強く反映されていることが先日ニュースになりましたね。それに対して、耐量子暗号のほうは、量子力学の原理が実装された新しい型のコンピュータ、すなわち量子コンピュータに対抗するための技術のことですよね。つまり、暗号を使用する自分は量子コンピュータを使っていなくても、攻撃者のほうは量子コンピュータを使えるという攻撃モデルを想定しています。そんな条件でも、解読することができない暗号技術のことを耐量子暗号といいます。ですので、耐量子暗号は、現在普及しているコンピュータを使って実装するものです。

 

高機能暗号、耐量子高機能暗号について

芦原:次にセキュリティの観点からすると、暗号はあくまでセキュリティを実現するためのひとつの手段であり、コストがかかるものというイメージがあります。こういったネガティブなイメージを払拭できる話をしたくて。そうですね…、まずは高機能暗号について話をしていきたいと思うのですが。

縫田:普通の暗号技術は、暗号化や認証技術など通信の安全性を守るのに特化したものです。高機能暗号と呼ばれる技術は、比較的新しい技術でして、安全性はもちろんあるのですが付加的な機能も充実させようという技術です。高機能暗号の例を挙げますと、準同型暗号(図参照)というものがありまして、暗号文がふたつ与えられた際に平文や秘密鍵なしで計算できる技術です。これは平文が仮に数値だったとすると、暗号化を解いて足して暗号化しなおすのではなく、暗号文のままで中身を加算できます。単なる安全性だけではなく、機能としてもより便利なものになっているということになりますね。これは一例であって、他にも検索可能暗号* 2、関数型暗号* 2 などといった技術もあります。

芦原:高機能暗号を企業で利用するという話ですと、自社でだけ使うようなシステムなら暗号化の必要はないと思いますが、例えばクラウド上のシステムなど、データ処理を外部委託するような環境の場合ですよね。不正だったり、事故だったりがあったとしても、安全性が保たれるようにしたい。暗号化技術はこういった状況で必要になってくる。

縫田:おっしゃるとおりで、クラウドの利用者側としては安全だと思いたいけれども、必ずしも言い切れないと思う人もいる。ですが、暗号化した状態でクラウドにデータを預けておいて、統計的な処理をするとして、暗号化したままで実現できるようになるなら完全には信用できないと思われるクラウド環境だったとしても、見られることはないだろう、と思える。

芦原:もし具体例を挙げるとしたら、どのような高機能暗号の利用の仕方がありますか?法的な理由などで、データ処理を外部委託したくても平文では外に出せない場合も考えられますよね?

縫田:そうですね…。例えばビッグデータ解析をするとき、個人の活動の履歴や、病歴、企業秘密、特許のアイデアなど、あまり外部に見せたくないようなデータを分析します。こういうときに先ほど言ったような準同型暗号を使えば、暗号化したままで分析を行うことができる。情報の利活用とプライバシーを守ることの両立になりますね。

芦原:準同型暗号ですと、既に実装されているものもありましたよね。準同型暗号を使ったソフトウェアが出ていて、使い始めている企業もあったと記憶しています。

縫田:この“高機能暗号”に先ほどまでお話をしていた“耐量子技術”が合わさると、安全性がより強固なものになります。それが“耐量子高機能暗号”というものですね。耐量子暗号と高機能暗号には、数学的な仕組みに共通点が多いという相性の良さもあります。

 

量子コンピュータの起源と研究について

芦原:耐量子暗号は、“量子コンピュータが実装されたときに対抗するための技術”といったことを話しましたが、ともすると量子暗号やこれを搭載した量子コンピュータが悪者であるかのように捉える方もいるかもしれません。そうではなくて、高性能なものを駆使して世の中を便利なものにしたいといった前向きな動機で研究が始まったわけですよね。

縫田:はい。高度な技術は大抵の場合、前向きな構想があって、理論的なところから出発します。量子コンピュータの起源は“量子計算”。1980年代に「例えば普通のコンピュータではなく、量子計算ができるコンピュータがあれば、量子力学的なシミュレーションが上手くできるのではないか」という希望的観測から始まりました。そして現在量子コンピュータをどう実現するのか、という段階ではありますが、いろいろな研究が進められている。

芦原:ただし、ポジティブな側面を机上の空論でふりかざしてばかりではいけない。何かを実現させるためにはリスクも考えなければなりませんよね。新しい技術を研究するうえでは避けられないことです。

縫田:そうですね。暗号の観点でインパクトがあった最初の研究結果は、1994年にPeter W. Shor氏が証明した素因数分解の量子計算アルゴリズムです。現行のコンピュータでの大きな整数の素因数分解には膨大な計算量を要しますが、インターネット等で使われる暗号の安全性は、この計算量の大きさに依存しています。もし量子コンピュータが実現されるとこういった暗号の安全性が崩壊する、としたのがShor氏の論文です。

芦原:現在公開されているRSA暗号や楕円曲線暗号の設計思想が破られてしまうということが明らかになったわけですから、それに対応できる暗号技術の研究を進めなければなりませんよね。

縫田:基本的に公開鍵暗号の安全性は、理論的に証明しきることはできません。よって実験で検証する。実験結果から導き出される予測で安全性が成り立っている、ということです。予測とはあくまで“確からしさ”ですので、明日その“確からしさ”が破られる可能性は否定できるものではありません。この信頼度をいかに高めるかは、暗号分野の課題のひとつです。

芦原:コンテストでその“確からしさ”の信頼性を高めようとする動きがありましたね。RSA Factoring Challenge*3なんかもそうでしたよね。

縫田:素因数分解をする対象がレベルごとに用意されていて、世界中の暗号の研究者が問題を解く。たくさんの人が解けない問題を自分が解ければ、優秀さを認められることになりますし、賞金が発生するものもあります。そうすると、漠然と研究をしているよりもモチベーションが上がりますよね。

芦原:そういう世界的に注目されているような場があれば、世界最強の暗号解読者でも解くことができない問題のレベルがわかりますよね。そうなれば、暗号の“確からしさ”をどこまでのレベルに設定しておけば破られないか、という目安がわかるとなるわけですね。

縫田:耐量子暗号でもこういったコンテストを開催しています。これは企業ではなく、大学が主導のコンテストです。大学が主導なのにはいろいろな理由があるとされていますが、耐量子暗号についてはこれから普及していくであろう、という段階だからというのがひとつ挙げられると思います。

 

米国における耐量子暗号の標準化動向について

芦原:今、まさに標準化が行われているのは公開鍵暗号ですよね。暗号化、鍵交換、デジタル署名といった公開鍵暗号の方式の選定が進行していて、第1回の安全性・効率性の評価が終わって、第2回の評価に進む方式の仕様や実装結果の更新版も出揃った状況ですね。

縫田:アメリカ国立標準技術研究所[以降NISTとする] * 4が標準化に向けた公募、という位置付けで2017年11月まで技術提案を募集していました。芦原さんがおっしゃったように、今は公開鍵暗号方式の選定時期ですね。理論的なことだけではなく実装も含めたものでして、仕組みがわかりやすい実装と、速度的な最適化も施した本格的な実装との2種類を提供すること、という募集のもと選定されています。

芦原:選定の仕方は、例えば、RSA Factoring Challengeのような?

縫田:NISTのWebサイトで公開する暗号方式に対して、世界中の耐量子暗号の研究者たちが安全性のチェックをしていく、というものです。早いものでは提案して数日で破られてしまうものもありますよ。

芦原:もちろん提案する側が簡単なものを提案しているのではありませんよね?

縫田:はい。私自身も携わったことがあるのですが、理論も実装もしっかりしていなければいけませんし、ドキュメントの整備もされていなければなりません。かなりの労力をかけて提案をするのですが、それでも1週間も経たずに破られてしまうということもある、ということです。

芦原: ナップザック暗号*5 みたいに、新しい方式が提案されてはすぐに破られて、というのを何度も繰り返している方式もありますし、なかなか上手くいかないものですね。

縫田:量子コンピュータは将来的に実現するかどうかもわからない技術です。それに対して今、暗号方式の標準化をしているというのは、つまり安全性評価を事前にしておかないと間に合わない、ということです。

芦原:例えばあと2~3年で量子コンピュータができそうですよ、というときに対応した暗号を用意する、となると、まだ安全が保障されていないものを実装せざるを得なくなる危険性がありますしね。

縫田:それから、暗号技術を移行する期間も考えるとかなり余裕を持って標準化を進めておかなければならないということもあります。素因数分解の問題は紀元前から研究されているとされていますが、RSA暗号はその素因数分解の難しさが基本です。研究にかけられた時間の長さが、安全性の確からしさの証左のひとつということですね。

芦原:そうですよね。そうなると、耐量子暗号の研究もかなり長い時間をかけないといけない。耐量子暗号の有力候補の中で比較的新しい格子暗号*6 8の問題についても、既に20年以上も研究され続けていますし、NISTの標準化計画が、年単位の時間をかけたものであることは必然といえそうですね。

縫田:2016年2月に福岡で開催されたPQCrypto(Post-Quantum Cryptography)*7 に私も参加したのですが、そこでNISTから耐量子暗号の標準化の具体的な計画が示されました。標準化の方針について、採用する技術をひとつに絞るのではなく、信頼できる技術の選択肢を利用者に提供できるようにすることが目的であると言っていました。

芦原:技術をひとつに絞ってしまうと、様々な状況に対応することが難しくなりそうですものね。つまり、利用する用途によってふさわしいものを選べるようにする、と。

縫田:はい。そうですね。ある種類の耐量子暗号は安全性が高いとされる一方で、公開しておく情報として、たくさんの数値をためておかないといけないので、例えば軽量デバイスみたいなところに組み込む場合などは、必ずしも適切とはいえないかもしれませんね。そういう場合には、小さな鍵で使える別種の耐量子暗号の需要も出てきます。ですので、メリットとデメリットを検討しつつ、用途によってどの性能を重視するのかを見極めることが重要になってくると思います。

 

セキュリティの観点からの準備について

芦原:弊社では脆弱性診断サービスを提供していまして、いまだに古い暗号の実装を検出することもあります(28ページ参照)。実際標準化を進めて移行できるまでに、どのくらいかかるものなのかな、という疑問があります。耐量子暗号でなくても通信できる期間があって最終的には完全移行がなされるまで、しばらくは移行期間が設けられると思いますが…。

縫田:そうですね。NISTの標準化の観点ですと多少意見はわかれますが、2030年ごろにはRSA暗号を破ることができる量子コンピュータが現れるだろうとされています。

芦原:耐量子暗号による通信でないといけないのは2030年辺りだろう、ということですね。

縫田:移行期間を予測するひとつの目安としては、現在RSA暗号に使われている鍵の大きさの今の標準、2048ビットへの移行に要した期間でしょうか。少し前までは1024ビットでしたね。コンピュータの性能の進化などによって1024ビットでは足りないとなったのが、2010年ごろでした。実際に世の中のほとんどのシステムが2048ビットに移行できたのにはおよそ5、6年かかったというデータがあります。今回はもともとのシステム自体を入れ替えるという作業になりますので、もっと時間がかかってもおかしくない。

芦原:計画では標準化ドラフト発行が2024年ごろ、そこから耐量子暗号への移行完了が2030年ごろの予定ですから、結構ぎりぎりのスケジュールですね。移行する方法、例えば、現状は既存のネットワーク上で TLSを使って暗号化通信をする場合は、公開鍵暗号で鍵交換や認証をしているわけですけれども、それの公開鍵暗号の部分を単純に耐量子暗号に置き換えるだけで機能するものなのでしょうか。

縫田:プロトコル全体の安全性をしっかりと調べるというのは難しいかもしれませんが、基本的には鍵の共有が終わった後の部分というのは、公開鍵型ではなく共通鍵型になりますので、そこまで大きな問題はないかなと思います。

芦原:共通鍵暗号の場合は、量子コンピュータを使うことによって、暗号の強度が鍵長の半分のものと同程度にまで落ちるため、ひとまず共通鍵の鍵長を2倍にすれば、それまでと同等の安全性を確保できると考えられていますよね?

縫田:実は少し問題がありまして、2010年に共通鍵も安全ではないという説が出まして、本格的に研究が始まりました。最初は割と限られた種類の方式だけに影響すると考えられていたのですが、もっと新しい研究だと、もう少し広い範囲の共通鍵暗号方式について量子コンピュータの影響がある、となりました。単純に鍵を長くすればよいというわけではないということが明らかになってきているので、耐量子といったときには共通鍵のほうも本当は注目しなければならない要素です。ただ2010年に研究が始まったばかりですので、まだ研究途上ではありますが。

芦原: 標準化が進められている公開鍵型の耐量子暗号だけでなく、共通鍵暗号についても、将来使い続けられるものであるかどうかを考えて利用しないといけないという問題がありそうですね。

縫田:もしかすると、2030年に間に合わせようとするなら準備を急がねばならない段階かもしれません。ただ、今は標準化の準備段階ですので、既存のシステムの中で使われている暗号を新しく置き換えるのは大変でしょうね。ですが、新しいシステムの導入からなら置き換えではないので、想定して作っておくことはできるのではないでしょうか。

芦原:そうなると、2030年以降も稼動させる予定のシステムについては、今の段階で新しい暗号方式に対応できるように設計するのがよさそうですね。

縫田:信頼できる選択肢をどれだけ提供できるかが研究者の使命であると考えています。


縫田 光司 氏(右)
東京大学 大学院情報理工学系研究科
数理情報学専攻 准教授
東京大学 理学部 数学科を卒業後、東京大学 大学院数理科学研究科 数理科学専攻 修士課程と博士課程修了。
情報通信や情報利活用の安全性を支える暗号・情報セキュリティ技術の研究を行っている。
論文・著書:Koji Nuida, Goichiro Hanaoka, “On the security of pseudorandomized information-theoretically secure schemes”, IEEE Transactions on Information Theory, vol.59, no.1, pp.635-652, 2013.ほか

芦原 聡介(左)
株式会社ブロードバンドセキュリティ(BBSec)
セキュリティサービス本部 セキュリティ情報サービス部
広島大学大学院理学研究科数学専攻修了 博士(理学)取得。その後、暗号技術の研究に従事し、 共通鍵暗号型検索可能暗号の動向についての論文を執筆。
産業技術総合研究所、日本銀行金融研究所を経て、株式会社ブロードバンドセキュリティ入社。
現在はセキュリティ情報のリサーチ・分析・配信などを行うアナリストを務めるほか、 ITセキュリティセミナーの講師としても活躍している。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。