DXとセキュリティ

Share

今回は、デジタル技術を活用して経済にイノベーションをもたらすDXと、そのセキュリティについて考えます。「DX」と「IT化」との違いや、日本企業のDXを阻害すると考えられている「2025年の崖」とは何か、そして、政府によるDX推進のための補助金などを紹介します。

また、DXと歩みを同じくするように進化を続けるサイバー犯罪に対応するための心構えについても、今回は考えてみたいと思います。

DXとは

DXは、Digital Transformation(デジタルトランスフォーメーション)の略称です。Trans(トランス)には「交差する」という意味があり、「Trans」を「X」と表記することがあるため(「X」は線が交差しているから)、「DT」でなく「DX」と略されます。

DXとは、デジタル技術を活用してビジネスやサービスを変革し、イノベーションを推進することです。

単なる「IT化」と「DX」の違い

これまでの「IT化」は、既存のビジネスにITを導入することによって、「効率化」「省力化」「高速化」を行いました。既存のビジネスプロセスや商習慣は大きく変わることなく、IT技術はあくまで「手間を減らすため」「少ない人数でできるようにするため」「以前よりも速くするため」に奉仕する存在でした。

一方でDXは、従来の方法を単に強化してサポートするだけではなく、デジタル技術が生み出すイノベーションによって、全く新しいビジネスモデルを生み出す点が異なります。

レガシーに足を取られて前進できない~DXを阻む「2025年の崖」とは

経済産業省は2018年、「DXレポート ~ITシステム『2025年の崖』克服とDXの本格的な展開~」と題した報告書を公開し、日本経済のDXを阻害する要因に対して警鐘を鳴らしました。「2025年の崖」とは、過去の「IT化」によって生み出されたシステムのメンテナンスに予算と人員がとられて、日本経済が停滞してしまうという予測です。

森喜朗首相(当時)によって「IT革命」が叫ばれた西暦2000年頃、NHFを代表とするシステムインテグレータ企業は、日本企業の複雑かつときに奇怪にすら見えたビジネス慣習に、いかに寄り添って微細にカスタマイズをして納品するか、その腕前を競い合いました。こうして複雑にカスタマイズされたシステムが年を経て技術が時代遅れになり、ブラックボックス化して機能追加もままならなくなり、管理も属人化してしまいました。

経産省のレポートでは、こうした新しい価値を生まないシステムの維持のために、IT投資の9割が使われ、それによって日本経済が停滞すると予測しています。まさに砂漠に水を撒き続けるような状態です。

技術的な負債となり得るIT投資

(出典:経済産業省「DXレポート ~ITシステム『2025年の崖』克服とDXの本格的な展開~」)

あなたの会社が今やろうとしていることは、このようなIT投資になっていないでしょうか。DXを進める際に注意したいポイントです。

DXの成功事例、Uberは何が革新的だったのか

配車サービスのUberは、DXの成功事例のひとつといえるでしょう。乗り合いサービスを提供したいドライバーと利用者をマッチングするアプリは、世界各国で使われています。GPSと地図、マッチングと評価の機能、Uberが用いているのは特段新しい技術ではありません。Uberが行ったのは、新しいビジネスモデルの創出なのです。

一方でUberは、ロンドンやニューヨークをはじめとする世界中で、タクシー業界を壊滅させるサービスとして猛反発を受けています。既存の業界やビジネスプロセス、商習慣に対して、ときに破壊的インパクトを与えるのもDXの特徴のひとつといえるかもしれません。

2025年の崖にも、DXによる解決方法はきっとあるはずです。

税金や補助金など、DX優遇あれこれ

人口減少社会に突入した日本経済の起爆剤として、政府はDXを強力に推進しています。2020年10月には、大手経済紙が、2021年度の税制改正で、DXを進める企業への税制優遇策を政府が検討していると報じました。

税制優遇は詳細がまだ明らかにはなっていませんが、その他にも「IT導入補助金」「DX認定制度」など、DXを推進するためのさまざまな施策が政府の後押しで行われています。あなたの会社でも利用できるものがあるかどうか、一度調べてみてもいいかもしれません。なお、2020年度の「IT導入補助金」交付申請締め切りは、2020年12月18日17時です。

革新が進むサイバー攻撃

残念ながら、サイバー攻撃もまた、DXによってイノベーションが進んでいます。これまでもサイバー攻撃は進化を続けてきましたが、サイバー犯罪にも質的変化や革新が起こりました。

たとえばランサムウェアは、1989年に初めて発見され、長らくパッとしないサイバー犯罪のひとつとして存在し続けていました。しかし2013年、身代金受け取りにビットコイン等の仮想通貨を用いるというビジネスモデルの刷新によって、一転「収益を生むサイバー犯罪」に変わりました。近年、暗号化して人質にしたデータの復号だけでなく、データを一般公開すると脅し二度金銭を要求したり、大事なデータをオークションで販売するなど、ランサムウェアは悪質化の一途を辿っています。

「DX with Cybersecurity」、SQAT.jpが考える3つのキーワード

内閣サイバーセキュリティセンター(NISC)は、報告書「サイバーセキュリティ2020 」の中で、「DX with Cybersecurity」として「サイバーセキュリティ対応能力の効果・効率を向上させるためにDXを推進する」と記載しています。

なかなか難しい「DXとセキュリティ」というテーマではありますが、SQAT.jpとしてあえて3つのキーワードを挙げてみましょう。

1.担当者だけではない

デジタル技術そのものが新しい価値と利益を生み出すDXでは、セキュリティは情報システム部門やセキュリティ部門、あるいは品質管理部門や経営企画だけが担えばよいものではなく、すべての部門が自分事として取り組む必要があります。事業会社であるなら、たとえ間接部門に所属していても全部署の人が利益を考えて活動しなければならないことと同じように、全社員がセキュリティを考えて動く必要があります。

2.能動的セキュリティ

これまでセキュリティは、攻撃を未然に防ぐよう対策を行い、万一事故が発生したらそれを受けて対応するのが常でした。しかしこれからのDX時代は違います。企画段階からセキュリティバイデザインで要件定義を行い、将来脆弱性を生まないように、コード診断を行いながらDevSecOpsで開発をスピーディに進めるなど、先手先手でセキュリティの試みを能動的に行うようになるでしょう。「シフトレフト」があたりまえになって、その言葉すらなくなるかもしれません。

3.持続・継続性

DXによって生み出されるサービスの多くでは、「新時代の石油」と呼ばれる「データ」、つまり、位置情報や決済情報、健康情報等と結びついた個人情報が、渦となって集積することになるでしょう。セキュリティを担保する活動を定常的に行い続けることが、DX時代の企業の新しい存在意義のひとつになると考えられます。そこでは、クラウドの活用や自動化の推進、優秀な人材の確保が欠かせません。また、SQAT.jpが提唱してきた「セキュリティのかかりつけ医」的な会社との関係を構築することも鍵になるのではないでしょうか。

DX時代もセキュリティの本質は変わらない

DX時代、セキュリティ業務はその対象をIoTやAPIにまで拡大し、その方法も様変わりしていくことが予想されます。しかし、脆弱性診断で隠れたセキュリティホールを探したり、脆弱性が報告されたらすばやくパッチをあてたり、日々パスワード管理を行ったりするなど、安全を守るための活動を日々積み重ねていくことの重要性に変わりはありません。

DXの時代はむしろ、全社にセキュリティの重要性が認識され、受け身だった仕事に能動的な側面が増えることで、セキュリティの業務の価値がいっそう高まっていくでしょう。

まとめ

  • DXとは、デジタル技術を活用してビジネスにイノベーションをもたらすことです。
  • 既存のビジネスにITを導入するだけの「IT化」とDXは異なります。
  • 複雑にカスタマイズされてブラックボックス化した既存システムは企業のDXを阻害します。
  • 政府は優遇税制や補助金などを用意してDXを推進しています。
  • サイバー犯罪もまた革新と進化を続けています。
  • しかしDX時代とはいえ、セキュリティ業務の本質は何ら変わるものではありません。

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


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

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

プログラミング言語の脆弱性対策を考える

Share

プログラミング言語のセキュリティは、組織のシステム全体のセキュリティに大きな影響を与えます。「アプリケーションの脆弱性の半数はC/C++に起因する」という報告もあり、プログラミング言語における脆弱性の特徴を理解し、適切な対策を講じることは、いまや組織のセキュリティに不可欠な取り組みといえます。本記事では、プログラミング言語の最新動向、脆弱性が生まれる背景を解説します。

プログラミング言語のトレンド

言語 使用している
開発者の比率
JavaScript69.7%
HTML/CSS 62.4%
SQL 56.9%
Python 41.6%
Java 38.4%
Bash/Shell/PowerShell 34.8%
C# 32.3%
TypeScript 28.3%
PHP 25.8%
C++20.5%
C 18.2%
Go 9.4%
Kotlin8.0%
言語 使用している
開発者の比率
Ruby7.5%
VBA6.2%
Swift6.1%
R5.5%
Assembly4.9%
Rust4.8%
Objective-C4.4%
Scala3.9%
Dart3.7%
Perl3.3%
Haskell1.8%
Julia0.9%

Stack Overflow Developer Survey 2020 より弊社作成
https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

JavaScript、HTML/CSS、SQLなどが上位に並んでいますが、皆さんの予想どおりでしょうか?ちなみに冒頭で述べた、「脆弱性の半数」を生み出すとされるC/C++に関しては、昨今IoTデバイスなどの組込機器やデスクトップアプリケーション等に利用目的が収れんしてきているといわれ、その使用率は減少傾向にあります。また、リストには記載がありませんが、日本に限ってみると、COBOLなどのレガシーシステム向けの言語がいまだ根強いシェアを保っているのはご存じの方も多いことでしょう。

なお、弊社での診断傾向としては、JavaScriptのほか、Pythonが目立っています。今後については、「オーバーヘッドが少なく、静的型付け言語である」という特徴をもつTypeScriptなどが、軽量さの望まれるサーバレス環境での需要につながるものとみられます。また、Android端末向けにKotlinの需要も高まると予測しています。以下、ご参考に、プログラミング言語と主な利用分野のマッピングを示します。

図:主要プログラミング言語と現在利用されている代表的分野

プログラミング言語の脆弱性 ― 言語ごとに異なる特徴を知る

プログラミング言語の脆弱性を考える場合、特定の言語に固有のものと、言語間で共通のものを押さえておく必要があります。

例えば、C/C++では、その脆弱性の7割がメモリハンドリングのミスに起因するといわれており、メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにすることが、重要なセキュリティ対策となります。そのほか、言語固有の脆弱性として代表的なものは、Javaでの「安全でない入力に対するデシリアライゼーション」の問題、JavaScriptでの「パストラバーサル」や「暗号」の問題、PHPでの「クロスサイトスクリプティング(XSS)」や「SQLインジェクション」などになります。

なお、2000年代後半以降にリリース開始された比較的新しいプログラミング言語(Kotlin、Golang、Rustなど)については、上記とは若干が異なる観点からの注意が必要です。まず、こうした言語では、セキュアコーディングのための様々な関数やライブラリなどが用意され、セキュリティに関する手厚い対策が組み込まれているのですが、その一方で、セキュリティの機能が増えれば増えるほど関連ドキュメントが膨大になり、把握が追いつかないという課題が生じています。例えば、Kotlinの場合、Kotlin自体のドキュメンテーションではセキュリティ関連の記述はNULLの安全性に触れる程度なのですが、セキュアコーディングに取り組もうとすると、膨大なAndroid Developer Guideを参照する必要があります。また、相互運用性への配慮も必要です。例えばKotlinやGolangはJavaと一緒に利用するケースが多いため、こうした言語で開発を行う場合には、Java側の環境を考慮したうえでのセキュアコーディングが不可欠になり、それが開発の難易度を押し上げているという状況があります。

プログラミング言語の脆弱性 ― 全言語に共通の特徴を知る

続いては、すべての言語に共通する脆弱性です。これは大きく以下の3つに分類できます。

情報漏洩
・表示する必要のない機微な情報(ユーザ名やIDなど)の露呈
・不要なシステム情報の公開
入力検証の不備
・不正なパラメータの許容、XSS、SQLインジェクション
・HTTPヘッダ分割
認可・認証関連の脆弱性
・オブジェクトやファイルなどへのアクセス認可の不備
・認証情報の保護機構や暗号化の不備

脆弱性が発生する背景

以上述べてきたような脆弱性は、なぜ発生するのでしょう。その背景には、開発現場における以下のような課題があると考えられます。

・プロジェクトベースで人員が変わることが多く、知識や経験の共有が行われることがまれ
・脆弱性やセキュアコーディングに対する意識、知識レベルがプログラマによって異なる
・ギリギリのスケジュールでプロジェクトが進むことが多く、知識や経験の共有まで手が回らない
・セキュリティへの対応が明示的な業務として遂行されるのではなく、プログラマやプロジェクトメンバー1人1人の善意に依存する面が強い

具体例で説明しましょう。先ほど、PHPではXSSやSQLインジェクション等の脆弱性がよく見られると述べました。しかし、PHPでも、バージョン4以降であれば「htmlspecialcharacters」という関数を利用することでXSSの回避に必要な特殊文字のエスケープ処理ができます。SQLインジェクションについても、プレースホルダの利用による回避が可能です。このように、すでに対策が存在する場合であっても、プログラマ間で知識や経験の共有が行われていない場合、ソースコード診断やステージング環境でのWebアプリケーション脆弱性診断が実施されない限り、脆弱性は放置されることになります。また、「機微な情報の露呈」という問題については、個人情報保護などの法制度に対する知識が共有されておらず、そもそも課題として認識されていないという可能性があります。なお、知識共有のハードルは、セキュリティ機能が充実しているゆえに把握すべき情報量が膨大で、他の言語との互換性等まで含めた配慮が求められる最近のプログラミング言語では、さらに高いといえるでしょう。

こうした課題を解決するには、プログラマ個人の知識・技術レベルを高めることはもちろんですが、それ以上に重要なのは、組織を挙げての体系的な取り組みであるといえます。

先手を打った対処がカギ

そこでぜひ取り入れたいのが、プログラミング言語に関わる脆弱性が生じていないかを、開発の初期段階から継続的に点検する取り組みです。これは「DevSecOps」とも呼ばれる考え方で、「開発(Dev)」・「運用(Ops)」に「セキュリティ(Sec)」の観点を組み込むことで、システムのセキュリティ強化を図るものです。開発プロジェクトは常に時間との闘いですが、だからといって脆弱性への対応を先送りしてはなりません。対処が事後になればなるほど、影響範囲が広がり、コストも肥大する恐れがあります。

以前の記事でも解説しましたが、何よりも、初期段階からの取り組みが重要です。例えば、人員の流動が激しいプロジェクトベースの現場では、開発の早期からソースコード診断を含むテスト活動を実施し、脆弱性をコード単位で効率的に解消していくことによって、各段階で積み上げられた知識や経験を、後続の工程で活用することが可能になります。また、近年主流になっているアジャイル型の開発手法でもこれは有効で、短い開発サイクルが繰り返される中で早期に・こまめにテストや修正を行うようにすることで、セキュリティを強化できるのみならず、プロジェクト全体の工数も抑制できます。なお、短いサイクルでテストを回すには、SaaSタイプのソースコード診断サービスの利用を検討してもよいでしょう。

先手を打って脆弱性に対処できれば、脆弱性の要因となっていた様々な課題に取り組む余裕も生まれます。結果として、セキュリティと開発効率をともに高められる好循環を実現できるのではないでしょうか。

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


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

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

テレワーク環境下における営業秘密の保護

Share

緊急事態宣言が解除されて1か月余り。通常勤務に戻る企業もあれば、テレワークを存続させる企業もあり、対応はさまざまです。不動産業界の調べによれば、東京都心のオフィスビルの空き室率は2020年3月以来微増しており、テレワークを今後も継続する企業は少なくないようです。

もともと欧州ではワークライフバランスの立場から在宅勤務(テレワーク)を推進してきました。オランダでは2016年に労働者が自宅を含む好きな場所で働く権利を認める法律が施行されています。フィンランドでも今年1月に同様の法律が施行されました。コロナ禍によってこうした動きは一層加速されており、米国は民間企業主体ではあるものの、やはり大手IT企業を中心に在宅勤務を義務化・恒久化する動きがあります。

しかしながら、日本においてはテレワークが欧米ほど浸透していません。国土交通省が今年3月に実施した「令和元年度テレワーク人口実態調査」では「会社でないと閲覧・参照できない資料やデータがあった」のは26.8%、また、セキュリティ対策に不安があったのは3.4%とありました。情報へのアクセス整備やセキュリティ対策不備に伴う漏えいへの不安がテレワーク推進の妨げになっていると考えられます。

テレワークにおける情報漏えいの不安

テレワークの場合、自宅での「在宅勤務」、出先や移動中に行う「モバイルワーク」、シェアオフィスなどを利用する「サテライトオフィス」のいずれにしても、インターネットを通じて業務データを社外で利用することに変わりありません。また、作業者が使用しているPCに重要なデータをダウンロードして作業する場合、セキュアゾーンで実施されないことも多いでしょう。そこにセキュリティ上の不安があるものと思われます。

総務省「テレワークセキュリティガイドライン第4版」においても、起こりうる事故として「情報漏えい」「重要情報の消失」を挙げています。確かに、企業が保有する設計図・製造ノウハウ・調査研究データなどの技術的な情報、取引内容・顧客リスト・財務データなどの営業上の情報は、事業存続および競争力強化にとって重要な情報資産であり、漏えいすることによるリスクははかりしれません。こうした懸念から、テレワークへの切り替えを躊躇する向きもあるでしょう。

そこで、適切にセキュリティを確保して情報流出の不安を解消しながらテレワークを実施できるよう、経済産業省は5月7日、「テレワーク時における秘密情報管理のポイント (Q&A解説)」を公表しています。以下に、そのポイントをみていきましょう。

「不正競争防止法」により保護される営業秘密(機密情報)

セキュリティ対策によって保護すべき、企業が保持する「営業秘密」は、一定の要件を満たすことで不正競争防止法の下で保護されます。法的保護を受けることにより、例えば電子データで取り扱われている機密情報がセキュリティの脆弱性を突かれて漏洩した場合でも、差止請求や損害賠償請求などが可能です。このため、事業における金銭的被害や信用失墜といったリスクを軽減できます。

ただし、営業秘密として法的に認められるためには、対象となるデータに対して以下の条件が整っていることが必要です。

1.秘密管理性:その情報が秘密であるとわかるように管理されていること
2.有用性:事業活動に役立つ情報であること
3.非公知性:世間一般に知られていないこと

「秘密管理性」の趣旨は、「企業が秘密として管理しようとする対象(情報の範囲)が、従業員等に対して明確化されることによって、従業員等の予見可能性、ひいては経済活動の安定性を確保する」ことにあるとされています。つまり、情報が営業秘密として保護されるためには、「秘密である」こと自体をはっきり示す必要があります。

「非公知性」は、営業秘密保有者の管理下以外では一般的に入手することができない状態とされています。このため、営業秘密としての条件を満たすには、容易に人に見られたり、聞かれたりしないようにしなければなりません。

テレワーク環境で営業秘密を保護する対策

テレワーク環境下で、秘密管理性と非公知性の要件を満たして情報を保護しつつ、情報漏えいを防止するには、状況に応じて以下のような対策が挙げられます。

状況別 対策の例
テレワーク対応導入の第一歩 ●営業秘密管理規程、情報取扱規定等をテレワークに即した内容に改訂
●諸規程の従業員に対する周知徹底
●情報に応じたアクセス権者の設定 等
業務における情報持ち出しおよび
社外からのアクセス
●データのファイル名や当該データ上に「㊙」(マル秘)・「社内限り」等の秘密であることの表示を付す*1
●情報のコピー・持ち出しにおける上長等の事前許可/返却・破棄ルールの周知・徹底と持ち出し記録の整備
●紙の資料・PC等を机上等に放置しないといった取扱いルールの徹底
●ID・パスワードによるアクセス制限の実施
●チャットツールで営業秘密についてやりとりするスレッドと参加者を限定 等
社外作業 ●PCにのぞき見防止フィルム等貼付の徹底
●音声が漏れない場所でのオンライン会議実施徹底
●公共無線LANの使用禁止、従業員のポケットWi-Fi・テザリングの禁止、業務使用Wi-Fiの貸与 等
情報漏えい、不正持ち出しの防止 ●メールの転送・添付制限、送信前の上長承認、上長のCC追加設定
●遠隔操作でPC内データを削除できるツールの利用
●PCに対するUSB、スマホ接続不可設定
コピーガード付き記録媒体の利用 等

営業秘密として秘密管理性要件を満たすと認められる技術的要素

テレワークにおける情報流出対策として規程を整備し、徹底した従業員教育を行ったとしても、所詮は人間が実施することであるため、悪意の有無にかかわらず、すべてが絶対確実に守られるとは言い切れません。そのため、前述の対策の例にも、技術的に強制するような仕組みがいくつか含まれています。

アクセス制御と権限管理の徹底

データ管理における秘密管理性要件については、通常、アクセス制御が実施されていることをもって、「秘密である」ことを示すと見なされています。これは、アクセス制御の基本的な考え方が、当該情報を知るべき者だけが情報にアクセス可能であるべきという「Need to Know」の原則に基づいていることと関係があります。アクセス制御とは、正規に承認されたユーザにのみコンテンツへのアクセスを許可するセキュリティ対策だからです。

このため、秘密管理性の要件を満たすためには、アクセス制御自体が適正に実施されている必要があります。例えば、同じアカウントを複数の従業員が使い回しているような状態や、パスワードに社員番号をそのまま当てはめていて他人が容易に推測可能な状況の場合、秘密管理措置を講じていないと判断される恐れがあります。

アクセス制御が「対象へのアクセスそのものを制御する」のに対し、「行為の実行権限を管理する」のが権限管理です。権限管理とは、ログインによってWebシステムやファイルサーバへアクセスするためのユーザを認証するシステムにおいて、各ユーザアカウントの役割を定義し、データに対する閲覧・編集等、実行できる処理についての権限を付与・管理することを言い、当該ユーザに対して必要最低限の権限を付与する「最小権限の原則(Least Privilege)」を適用します。データの重要性や種類に応じて、特定のグループだけが編集権限を持ち、他の従業員には閲覧のみを許可するといった設定です。

適正なアクセス制御・権限管理のどちらが欠けても「脆弱なシステム」であると言わざるを得ません。

認証機構の堅牢化

アクセス制御に欠かせない認証機構ですが、IDとパスワードによる単要素認証は、リスト型ハッキング攻撃等の標的となりやすいため、テレワーク導入・継続に備え、パスワード強度に対するポリシーの見直しをお勧めします。現在、セキュリティの各種基準・仕様においては8文字未満のパスワードは脆弱であるとみなされており、14文字以上のパスワードが推奨されています。流出したパスワードや汎用的で推測容易なパスワードを排除する実装の導入も有効です。

しかしながら、ユーザにとっては長いパスワードを複数覚えておくのは至難の業であるため、パスワードの使いまわしもなくならないでしょう。これを防ぐには、ID/パスワード以外に、認証要素(指紋や顔等の生体認証、またはワンタイムパスワードトークンやSMS等の所有物認証)を1つ以上追加した、多要素認証の導入をお勧めします。

この他、データの管理についても注意が必要です。データをUSBやDVDに記録できないようにする、プロジェクト終了後のデータ消去について確認する手段を講じるなどです。

テレワーク導入・継続における技術的要素について、詳しくはこちらもご参照ください

法的要件の確認にも有効なセキュリティ診断

営業秘密として保護されるべき法的要件を技術的な側面で満たしているかどうか確認する有効な手段に、セキュリティ診断があります。営業秘密に当たる情報を扱っているWebアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT機器等に対し、第三者であるセキュリティ専門企業による診断を受けることをお勧めします。

先に述べた、アクセス制御や権限管理が適切に導入・運用されているかも、セキュリティ診断によって確認できます。

自らは気づいていない脆弱性を洗い出して悪用された場合のインパクトを事前に調査し、技術的に対応できること、対応が難しければ法的保護を受けるために講じるべき回避策や代替手段として何を整備しておくべきかを検討するなど、リスク対応策を検討しておくことが事業継続の肝となります。


参考情報

・テレワーク時における秘密情報管理のポイント (Q&A解説)
https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/teleworkqa_20200507.pdf

・逐条解説 不正競争防止法
https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/20190701Chikujyou.pdf


まとめ

・テレワークは緊急事態宣言後も一定の割合で継続される見込み
・テレワーク導入・継続における情報流出の不安には、経済産業省による「テレワーク時における 秘密情報管理のポイント (Q&A解説)」が対策のヒントになる
・テレワーク環境下でも、会社の重要情報を「不正競争防止法」による法的保護の対象である「営業秘密」として管理することが肝要
・適正なアクセス制御と権限管理は営業秘密の秘密管理性要件を満たす技術的なセキュリティ対策である
・機密情報を扱うシステムに対するセキュリティ診断の実施は、リスク対策における技術的な対応策と法的保護策の切り分けにも活用できる

関連情報

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

●<コラム>「ゼロトラストアーキテクチャ」とは?

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


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

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

見えない部分のセキュリティは忘れられがち
―メモリ領域の安全を考える―

Share

いまメモリの安全に関して、その重要性がますます注視されています。OSやアプリケーションを動作させるために必要なデータやプログラムは、そのほとんどが一度メモリ領域に展開されているため、メモリ領域が侵害された場合、実行中のソフトウェアから生きた情報が抜き出されてしまいます。にもかかわらず、メモリ領域のセキュリティは忘れられがちです。本記事では、メモリ領域に存在する脆弱性の脅威と、それを保護するためにどのようなセキュリティ対策を講じればよいのかについてご紹介します。


「メモリ」はコンピュータ用語では「記憶装置」や「記憶媒体」のことを指し、「メモリ領域」とは、その記憶媒体に保存されたプログラムを実行するときに、当該プログラムをロードするメモリの記憶領域を指します。つまり、OSやアプリケーションを動作させるために必要なデータやプログラム、プログラムの実行ロジックそのものまで、すべてがメモリ領域に存在しているといえるため、セキュリティ対策を行う上ではメモリ領域の安全を考えることが非常に重要となります。メモリ領域が侵害されると、実行中のソフトウェアから生きたデータを抜き出すことが可能となり、機微情報が悪意ある第三者に漏洩したり、プログラムの処理が改竄されることで不正に実行されたりする危険性があります。

2020年5月、Googleは2015年以降にChromeのコードベースで存在が確認された重要度の高い脆弱性のうち、約70%がメモリの安全性に関する問題であることを明らかにしました。メモリの安全に関する問題については、過去にMicrosoft社も同様に警鐘を鳴らしており、世界全体で毎年登録・公開される脆弱性において、常に20%程度をメモリ関連の脆弱性が占めています。

図1:Chromiumプロジェクトにおけるhigh以上の脆弱性

解放済みメモリに関連する脆弱性
他のメモリ関連の脆弱性
その他
セキュリティ関連のアサート

出典:
https://www.chromium.org/Home/chromium-security/memory-safety
より当社翻訳

普段OSやアプリケーションを使用する際、動作過程においてメモリ領域でどのような処理が実行されているかを深く意識する人は少ないでしょう。プログラムは、メモリ領域にすべてを展開して処理します。プログラムそのものもメモリ領域に存在しており、接続する各種デバイスも連携時にメモリ領域にて処理や制御が行われています。そんなシステムの根幹だからこそ、メモリ領域のセキュリティは万全であるべきですが、残念ながら脆弱性は存在し、攻撃者にとって格好のターゲットとなりえます。

図2:「メモリ領域への展開」の概要

メモリ関連の脆弱性、特にメモリ領域に関連する脆弱性の原因は、主にC/C++のポインタ周りのコーディングミスによるもので、代表的な脆弱性として、バッファオーバーフロー、領域外読み取り、Use-after-free(解放済メモリの再利用)といったものがあげられます。C/C++のメリットの一つにメモリ領域管理での柔軟性があり、それが処理の高速性をもたらす一方で、脆弱性を生み出すという皮肉な結果に結びついているのです。

図3:主要プログラミング言語と現在利用されている代表的分野

メモリ領域を狙った攻撃にはステルス性が高く、一般的な攻撃検知策では検知が困難なケースもあり、また、被害も甚大となる可能性があります。近年ではニュース等で「Spectre」、「Meltdown」といった単語をよく耳にしたことでしょう。これらはCPUの脆弱性を突くものですが、メモリ領域へのアクセスにおいて、CPUを介さずに各種デバイスとメモリ間でデータ転送を直接行うDMA(Direct Memory Access)にもセキュリティ脅威は存在します。DMA攻撃については、Thunderbolt経由でデータへの完全なアクセスを得ることが可能となる「Thunderspy攻撃」が記憶に新しいかもしれません。DMAはメモリへの直接アクセスによりデータ転送の高速化を実現する一方で、その有効性が攻撃者に逆手に取られ、悪用される事態が後を絶ちません。

プログラムの実行順序や構造が、まるでスパゲティが絡まったように複雑に入り組んでおり整然としないプログラムを「スパゲティプログラム」などといいますが、昨今はメモリ領域内でも複数のアプリケーションや制御処理が複雑に連鎖・連携・連動し、似たような状態に陥っていることも珍しくありません。こうしたすべてを把握することは困難であり、将来においてはさらに複雑化していくでしょう。

メモリ領域は「美味み」と「鮮度」を兼ね備えており、攻撃者にとっては非常に魅力的なターゲットといえます。また以前に比べて、現在は標準的なシステムでもメモリ領域は潤沢で、迅速な処理が実行可能となったことや、リソースの利便性が向上したことにより、今後もメモリ領域への依存性が高まることは容易に想定されます。

潤沢となったメモリ利用例
・クラウド環境などの仮想化
・外部媒体とのデータ通信
・AI化およびビックデータの統計処理

以上の点から、メモリ領域を保護するためにセキュリティ対策として、システム自体、あるいは周辺機器に対する物理的な対策を除いた場合、一例として次の3つの観点と対策が考えられます。


実行プログラムに対する脆弱性対策
メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにする。

アプリケーションを実行させる環境に対する脆弱性対策
パッチの適用やアップデートなどを徹底し、プラットフォーム環境や関連するデバイス制御などに既知の脆弱性がないことを確認する。

メモリ領域を防御するセキュリティソリューションの導入
アプリケーションメモリファイアウォール等、メモリ領域の保護に特化したソリューションを導入、運用する。


メモリ領域には多種多様なプログラムが存在し、連携・連動しています。そのため、小さなセキュリティホールでも悪用されれば大きな被害を生む恐れがあります。プログラムも所詮、最終的には人間が作るものであり、「人間はもともとミスを起こしやすい動物である」とは人間工学でもいわれていることです。どんなに完璧なコーディングをしたと思っても、複雑化された構造の中にミスやエラーが埋もれてしまっているかもしれません。開発において当然テストはするでしょう。しかし、セキュリティを考慮しないテストでは正常動作の確認が主であり、『アクセス違反』(Access Violation)を見つけることに集中しがちです。

そのため、メモリ領域の脆弱性に関連するセキュリティ向上策の一つとして、セキュリティの観点からテストを行う「ソースコード診断」の実施も有効と言えるでしょう。

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


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

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

テレワーク環境に求められるセキュリティ強化

Share

6月21日に内閣府が公表した「新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」によれば、新型コロナ対策で外出自粛が求められた後、全国でのテレワーク実施率は全国で34.6%、首都圏では48.9%にものぼります。

また、今後もテレワークを断続的ではあっても継続したい就業者は34.6%、首都圏で48.9%と、テレワーク実施率とほぼ同数であることから、今後もテレワークは一定の割合で継続するとみて差し支えないでしょう。

しかし一方で、コロナ禍以前からテレワークを推奨して準備していた組織ばかりでなく、 急遽、テレワークに移行したという組織も少なくありません。このように急遽実施されたテレワークでは、業務自体が成立することがまず優先され、必ずしもセキュリティの配慮がなされていたとは限りません。特に、テレワークで使用するクラウドサービスの認証情報を狙うフィッシング詐欺に関する社員教育や、在宅勤務でセキュリティ強度が低いホームネットワークを経由して業務を行うことのリスク対策について準備万端であるといいきれる組織ばかりではなかったでしょう。

そうした環境下でのテレワークはサイバー攻撃の格好の対象ともいえます。政府や警視庁もテレワークのセキュリティに関する注意喚起をおこなっていますが、具体的にどのような点に気をつければよいでしょうか。

テレワークとは

総務省によれば、テレワークは「ICT(情報通信技術)を利用し、時間や場所を有効に活用できる柔軟な働き方」と定義されています。

テレワークの形態は、自宅を勤務場所とする「在宅勤務」、出先や移動中に作業する「モバイルワーク」、本社から離れた営業所やシェアオフィスなどを利用する「サテライトオフィス」の3つに分類できます。

在宅勤務によるテレワークには、子育てや介護で通勤が困難な従業員でも離職せずに済むメリットがある上、最近では、台風やコロナなど、従業員が出社できない状況でも事業を継続するBCP的側面での活用が見られます。政府も「働き方改革」の旗手として期待をよせており各省庁をはじめ、地方自治体においても、導入に対する相談窓口や助成金を用意しています。

テレワークのセキュリティの基本的考え方

テレワークを推進する総務省は、セキュリティの重要性に当初から着目し、2004年から「テレワークセキュリティガイドライン」を刊行しています。改訂が進み、最新版は2018年の第四版です。

ガイドラインでは、テレワークを実現する方法を「リモートデスクトップ」「仮想デスクトップ」「クラウド型アプリ」「セキュアブラウザ」「アプリケーションラッピング」「会社PC持ち帰り」の6つのパターンに分け、脅威を「マルウェア」「端末の紛失や盗難」「重要情報の盗聴」「不正アクセス」とし、起こりうる事故として「情報漏えい」「重要情報の消失」「作業の中断」を挙げています。

図:テレワークにおける脅威と脆弱性について

(画像出典:総務省:テレワークセキュリティガイドライン第4版より一部抜粋)

また、「経営者」「システム管理者」「実務担当者」別に、それぞれの事故やリスクへの具体的な対応策を整理し、「ルール」「人」「技術」3つの分野でそれぞれに弱点がない、バランスがとれた対策が肝要であるとしています。

テレワーク環境下の人を狙ったサイバー攻撃

総務省ガイドラインが示す「ルール」「人」「技術」の中でも、特に忘れてはならない重要ポイントは人の問題です。令和元年度の情報通信白書においても、「ソーシャルエンジニアリング」が再び攻撃の中心になるという予測を紹介しています。先の内閣府の調査でも26.7%の人がセキュリティ面での不安を抱えています。

ソーシャルエンジニアリング対策としては、警視庁が「そのテレワーク、犯罪者が狙ってる!」と題する動画や、短編アニメ「テレワーク勤務時のセキュリティ基本篇」、啓発チラシ「ちょっと待って! そのテレワーク、セキュリティは大丈夫?」などを公開配布しています。

オフィスでみんなが席を並べて仕事していたら、いつもと違うメールが着信しても「こんなメールが届いた」と、隣席の同僚や情報システム部門に気軽に相談することができます。しかしテレワークではそれが簡単ではなくなります。人間心理の隙間を衝くような標的型攻撃メールなどに今まで以上に警戒が必要です。

また、政府のセキュリティ機関である内閣サイバーセキュリティセンター(NISC)は2020年4月、「テレワークを実施する際にセキュリティ上留意すべき点について」と題したテレワークに関する注意喚起を行っています。

NISCの注意喚起では、「政府機関」「重要インフラ事業者」「国民一般」の3つのカテゴリー毎に、セキュリティポリシーやルール整備、ICT環境の準備、安全な接続方法であるVPNやリモートデスクトップなどの技術活用にあたっての留意事項、遠隔会議システムの安全な利活用、機器のアップデートやパスワードの複雑化など、必要なセキュリティ対策がリストアップされています。

さらに、ノートPCの支給が間に合わずに個人端末の使用を許す場合もあり、これまでのような情報システム・IT部門による一括管理は難しくなりました。情報システム部門が個人端末に対してどこまで管理できるかの法的な問題もあります。また、一般社員に向けて、テレワークのセキュリティの留意点を告知したとしても、すべての社員がその内容を理解できているとは限りません。従業員向けの通達の意味が分からない場合、そのまま放置される可能性はどの程度あるでしょうか。それがリスクにつながるのであれば、通達の方法を変更するべきです。全従業員による確実な実施を徹底するため、情報システム部門からの通達内容において、使用されているIT用語は読み手のスキルレベルに対して適切か、耳慣れないと想定される言葉やプロセスは図を使用するなどして誰にでも等しくわかるような説明がなされているか、といった観点の校閲を設けるくらいの心構えが必要です。

アフターコロナのセキュリティチェック

緊急事態宣言解除後、徐々にオフィス勤務に戻る組織も多いでしょう。先に述べたようなセキュリティ対策レベルの低い一般家庭環境で作業していた機器をいきなりオフィスの環境に戻すのは危険です。

NPO日本ネットワークセキュリティ協会(JNSA)が「JNSA 緊急事態宣言解除後のセキュリティ・チェックリスト解説書」を公表しています。

テレワークを継続する組織も、オフィスワークに戻す組織も非常時稼働から通常稼働に移行する前にこうしたチェックリストを参照してセキュリティ点検をするのが望ましいでしょう。

セキュリティ診断もリモートで実施可能

情報システム部門が安全のためにできることがもうひとつあります。それは、リモートワーク環境を構成するVPN機器や認証サーバ、クラウド環境の接続拠点といったアクセスの出入り口における設定不備や、不正アクセスの原因となりうるセキュリティ上の欠陥の有無について、ハードやソフト面のセキュリティ診断を行うことです。

Webアプリケーションの脆弱性診断や、脆弱性が悪用された場合のインパクトを事前に調べるペネトレーションテストといったセキュリティ診断の多くは、インターネットを介して行うことができます。今回の新型コロナ感染症対策でテレワークを経験した企業では、今後もテレワークを希望する人が少なくありません。今後もこうした働き方を継続するのであれば、一度は脆弱性の有無を確認し、安全な環境で業務を行えるよう環境を整備することをお勧めします。

まとめ

・新型コロナウイルス感染拡大にともなってテレワーク実施率は倍増した。
・多くの組織が拙速にテレワークに移行したためセキュリティの課題がある。
・まずは警視庁や内閣サイバーセキュリティセンターの注意喚起を参照。
・総務省の出している詳しいガイドラインに沿って「ルール」「人」「技術」を見直そう。
・アフターコロナに対しては通常業務に戻る前にセキュリティ点検をしよう。
・VPN機器やクラウド環境などテレワーク環境全体のセキュリティ診断を受けよう。

関連情報

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

●<コラム>「ゼロトラストアーキテクチャ」とは?

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


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

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

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

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コーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

自動車ハッキングの今

Share

SQAT® Security Report 2019年10月号掲載

自動車業界のトレンドは「Connected(コネクティッド化)」「Autonomous(自動運転化)」「Shared/Service(シェア/サービス化)」「Electric(電動化)」の頭文字をとった「CASE」という言葉に集約されつつある。自動車は外部ネットワークと繋がり、新しい価値が創出されようとしているが、販売されている自動車の多くはセキュリティ対策が不十分なため、ハッキングの脅威に晒されている。


車載ネットワーク「CAN」

自動車内には主に四種類のサブネットワークが存在している。エンジンやブレーキの制御をつかさどる「制御系」、ドアやエアコン、シートやミラーを制御する「ボディ系」、カーナビやカーオーディオを制御する「マルチメディア系」、エアバッグなどの安全機能にかかわる部品を制御する「安全系」である。そしてそれらは、多くの車では制御の要となるCAN(Controller Area Network)を中心に、様々な機能を付加する形で車載ネットワークを構成している。

自動車ハッキングにおいて主に狙われるのがこのCANである。CANは1980年代にドイツのボッシュ社で開発された非常にシンプルなプロトコルで、その簡潔性、柔軟性、低コスト性から、今なお多くの自動車で採用されているほか、鉄道、航空機、船舶にも利用されている。

自動車に最も求められるのは、「走る」「止まる」「曲がる」に関する高い安全性であるが、CANは高い電磁ノイズ耐性と早く確実なレスポンス性能を持ち、安全性に対する多くの要求に応えるものだった。

一方で車が外部ネットワークに繋がったことによって、CANはセキュリティに関する多くの問題を抱え、安全性すらも脅かされている。Flex Ray のようなCANに代わるよりセキュアなプロトコルも登場してきているが、その採用は現状ではまだまだ限定的である。

自動車の未来

コネクティッドカーの登場により外部ネットワークに繋がれた自動車は、インターネットを経由した攻撃や、車車間通信を経由した攻撃に晒されている。今後自動運転車が本格的に市場に投入されるようになれば、外部ネットワークへの接続からのリモート操作が人命にかかわる大事故につながる恐れがある。また、EV充電や課金を伴う新サービスの登場により車がクレジット情報を直接的に扱うようになれば、それを狙った犯行の発生も予想される。

Electronic Control Unitの略称。自動車に搭載された様々な機能や装置を電子制御するためのコンピュータ。現在では車載ネットワーク上に100以上のECUが接続されることも珍しくない。

自動車にもセキュリティを考えなければならない時代が来ている。
自動車向けのサイバーセキュリティガイダンスであるSAE J3061*5 を取り入れたり、設計段階からのセキュアコーディング、さらに実車に対する脆弱性診断を実施したりするなど、今後ますます対策が必要になるであろう。

(左)燃料噴射量を調整してエンジンの回転数を増やす操作 (中)(右)燃料計の表示を操作。走行中に操作されればパニックになる可能性があるほか、攻撃のための細工を施した特定の燃料スタンドに立ちよらせるために利用することもできるだろう。

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コーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

高まるAPT攻撃の脅威

Share

SQAT® 情報セキュリティ瓦版 2020年1月号

あらためて、「侵入前提」の備えを

「攻撃のターゲットに定めた組織に対し、高度かつ複雑な手法を用いて長期間にわたり執拗な攻撃を行う」―「APT」と呼ばれるタイプの攻撃の矛先が、今、日本にも向けられるようになっています。従来、APTには侵入を前提とした多層防御が有効とされてきましたが、国際的に注目度の高いイベントであるオリンピック・パラリンピックが目前に迫り、日本を対象とした攻撃がこれまでになく増えると予想される中、あらためて自組織の状況を点検し、セキュリティの強化を図る必要があります。


APT28とは

「APT」とは「Advanced
Persistent Threat」(直訳すると「高度で持続的な脅威」)の略語で、日本では主に「高度標的型攻撃」という呼称が使われています。「標的型攻撃」は、文字どおり、特定の組織をターゲットにした攻撃を指します(図1参照)。この中でも高度な手法を用いた長期にわたるものが「APT」とみなされます。狙いを定めた相手に適合した方法・手段を用いて侵入・潜伏を図り、攻撃に必要な情報を入手するための予備調査も含め、執拗に活動を継続するのが特徴です。なお、セキュリティ機関や調査会社では、こうした攻撃が確認されると、攻撃の実行主体(APTグループ)を特定し、活動の分析に取り組みます。グループを追跡する際は、組織が自ら名乗る名称に加え、多くの場合、「APT+数字の連番」(例:「APT 1」「APT 2」)がグループ名として使用されています。

図1:標的型攻撃の主な手口

https://www.npa.go.jp/publications/statistics/cybersecurity/data/R01_kami_cyber_jousei.pdf

広範かつ大規模な攻撃活動

これまでに特定されたAPTグループの数は、上記連番方式により同定されているグループだけでも約40に上ります。国家レベルの組織による支持や支援を受けているとみられるものも多く存在し、その攻撃は高度であるだけでなく、広範かつ大規模です。直近では2019年10月に、ロシアの支援を受けているとみられる「APT28」(自称「Fancy Bear」)による脅迫メールが世界的な注目を集めました。

脅迫の手口は、「攻撃対象の組織のWebサイト、外部から接続可能なサーバ・インフラに対するDDoS攻撃を予告し、それを回避するための費用として仮想通貨を期日内に支払うよう要求する」というもので、危機感を煽るため実際にDDoS攻撃を行ったケースもありました。ペイメント、エンターテインメント、小売といった業種の複数組織を対象に同グループによる脅迫メールが送付されていることを、ドイツのセキュリティベンダが特定し、その後、JPCERT/CCにより日本国内においても複数の組織が同様のメールを受け取っていることが確認され、注意喚起が出されています。なお、同グループは、2016年の米大統領選挙のほか、政治団体やスポーツ団体などをターゲットにした攻撃への関与も疑われています。

 

地域・文化を超えるサイバー攻撃

従来、APT攻撃は主に欧米の組織を標的にしており、日本語という言語の特殊性などがハードルとなり日本企業は狙われにくいとの認識がありました。しかし、近年は、巧みな日本語を使用した、明らかに日本企業を標的とする攻撃が増加傾向にあります。

たとえば、独立行政法人情報処理推進機構(IPA)に報告されたサイバー攻撃に関する情報(不審メール、不正通信、インシデント等)の2019年の集計結果では、9月末時点で寄せられた攻撃情報、計897件のうち235件が標的型とみなされており、直近の7月~9月でその比率が顕著に上昇しています(表1参照)。当該データ113件のほぼ9割がプラント関連事業に対する攻撃で、実在すると思われる開発プロジェクト名や事業者名を詐称し、プラントに使用する資機材の提案や見積もり等を依頼する内容の偽メールが送信されています。IPAは、「現時点では、攻撃者の目的が知財の窃取にある(産業スパイ活動)のか、あるいはビジネスメール詐欺(BEC)のような詐欺行為の準備段階のものかは不明」としつつも、特定の組織へ執拗に攻撃が繰り返されていることから、これらをAPT攻撃の可能性がある標的型メールの一種に位置づけたと説明しています。

出典:サイバー情報共有イニシアティブ(J-CSIP)運用状況[2019年1月~3月]、[2019年4月~6月]、[2019年7月~9月]より当社作成

同様の傾向は、他国のセキュリティ機関の分析からも伺えます。タイのCSIRT組織ThaiCERTによるレポート『THREAT GROUP CARDS: A THREAT ACTOR ENCYCLOPEDIA』(2019年6月公開)を見ると、日本をターゲットに含めた攻撃は、もはや少ないとは言えません。たとえば、「Blackgear」と呼ばれる攻撃グループは日本を明白なターゲットにしており、C&Cの拠点を日本に置き、日本語の文書を使って攻撃を仕掛けます。また、2018年に確認された東南アジアの自動車関連企業をターゲットとした攻撃では、タイミングを同じくして特定の日本企業への攻撃が複数回観測されています。さらに、ターゲットとされる業種や狙われる情報の種類が多様であることも目を引きます。かつては、銀行のデータや個人情報がまず標的になりましたが、ここ数年、ターゲットの業界が航空宇宙・自動車・医療・製薬へとシフトし、ブラックマーケットでの高額取引が期待できる、各業界に固有の技術情報や特許出願前情報の奪取へと、攻撃目標が変化しています(表2参照)。

出典:『THREAT GROUP CARDS: A THREAT ACTOR ENCYCLOPEDIA』より当社作成

個人情報が流出した場合の損害賠償や事態収拾のための費用などを含めた事後対策費は平均6億3,760万円 1) と言われていますが、技術情報が流出した場合の想定被害額はその数十倍、数百倍に及ぶ可能性があります。技術情報のみならず、いわゆる「営業秘密」とされる知的財産の流出は、事業活動の根幹を揺るがす事態に発展しかねない規模の損失を招く恐れがあります。近年各社により提供されるようになっているサイバーセキュリティ保険等で損害補償対策を検討するのも一案ですが、国家の関与が疑われるAPTグループの攻撃被害については保険金が支払われない可能性もあります。より甚大な被害をもたらす攻撃を行うグループが、今、日本企業を新たな標的に定めつつあるという事実は、国内のあらゆる事業者が共有すべき攻撃の傾向となっています。

 

より強靭な「多層防御」でAPT攻撃の影響を最小限に抑える

APT攻撃への対策としては、従来、侵入を前提とした多層防御が有効とされてきましたが、足元でAPTグループによる日本への攻撃が増加傾向にある中、あらためて、多層防御の状況を点検し、攻撃耐性を高めていくことが求められています。防御策としてまず思い浮かぶのは、出入口を守るファイアウォールやUTM(統合脅威管理)、既知の脆弱性への対応などですが、それだけでは十分とは言えません。

APT攻撃での代表的な手口は、ターゲットにした組織への侵入を試みる目的で使用される標的型メールです。この入口対策を考えると、疑似的な攻撃メールを用いて開封率などを可視化して「ヒト」に対する教育訓練を施す「標的型メール訓練」は検討に値する対策の1つです。留意したいのは、開封率の低減を最重要視するのではなく、「開封されても仕方なし」というスタンスで取り組むことです。訓練の目標を「開封された後の対応策の見直しと初動訓練」に設定し、定められた対応フロー通りに報告が行われるか、報告を受けて対策に着手するまでにどれくらいの時間を要するかを可視化して、インシデント時の対応フローおよびポリシーやガイドラインの有効性を評価することをお勧めします。また、従業員のセキュリティ意識を向上させるために、教育および訓練と演習を実施するのが望ましいでしょう。

また、「多層防御」対策を立てる前提として、情報資産の棚卸しも重要です。日本企業は、他国に比較して、知的財産の重要性に対する認識が低く、情報の所在や管理が徹底されていないという指摘があります 3) 。組織内に存在する情報に関し、機密とするもの、公知であってよいものを分類し、それらがどこに格納されて、どのように利用されているかを可視化した上で、防御の対応をする機器・人・組織といったリソースを適切に振り分けて防御する仕組みを構築することが求められます。こうした仕組みは、侵入の早期発見にも繋がり、事業活動の継続を左右する重要情報へのアクセスを遮断することで、万一侵入を許しても被害を最小限に抑えられます。さらに感染経路・奪取可能な情報を洗い出し、感染範囲・重要情報へのアクセス状況・流出経路などを可視化できれば、システム内部へ拡散するリスクを把握することもできます。この「標的型攻撃のリスク可視化」により、「出口」対策へ効果的にリソースを有効活用することで、実効性をさらに効果的にリスク評価することが可能になります。

2020年、オリンピック・パラリンピックがいよいよ目前に迫り、日本への攻撃がさらに激しさを増していくと予想されます。同イベントには膨大な数の事業者が関与するため、セキュリティ的に脆弱な組織がAPT攻撃を受け、サプライチェーンやIoTを通じて被害が歯止めなく広がるリスクが大いに懸念されています。既存のセキュリティ体制をあらためて点検し、強靭化を図ることで被害を最小限に食い止めましょう。


注:
1)JNSA:2018年情報セキュリティインシデントに関する調査結果より
2) 同一のグループに対し、セキュリティ機関による命名、攻撃グループによる自称などを列挙
3) コンサルティング会社PwCが2017年に実施した調査より
(https://www.pwc.com/jp/ja/knowledge/thoughtleadership/2018/assets/pdf/economic-crime-survey.pdf)日本における「組織がサイバー攻撃の狙いとなった不正行為」の種類を問う質問で「知的財産の盗難」と回答した比率は25%で、世界平均の12%と比べて顕著に多い数字となった。

参考情報: *1 https://www.thaicert.or.th/downloads/files/A_Threat_Actor_Encyclopedia.pdf

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で行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。