Archive

継続的な認証とは、システム、アプリケーション、デバイスの間を行き来するユーザーのアイデンティティをリアルタイムに検証する機能を提供する、将来の「完全な状態」のセキュリティの概念のことです。 理論的には、継続的な認証ソリューションは、さまざまな監視ソースからのリスク信号を使用してユーザーを認証し、潜在的な脅威を特定し、侵害されたとフラグが付けられた認証情報の機能を積極的に修復します。 しかし、今日、継続的なユーザー認証は概念にすぎず、まだ確立された規格ではありません。 業種全体で現在使用されている従来の認証方法は静的であり、ユーザーは認証ワークフローの開始時にのみ、認証要素(例:パスワードまたはPIN、ワンタイムパスコード、生体認証)の提供に積極的に参加する必要があります。 概念的には、継続的な認証は、地理位置情報、生体認証の変更、さらにはキーストロークやマウスパターン、コンテキスト、その他の活動パターンなどの動作監視など、機械学習をベースとするインテリジェントなリスク監視ソースへの積極的な参加に取って換わるものか、または補強するものです。 継続的な認証への取り組み 継続的認証の背後にある明確な推進力： サイバー攻撃はその数と精巧さを増し続けており、データ侵害の61%はユーザー認証情報が根源となっています。 SMSベースのOTP（ワンタイムパスワード）のような従来のセカンドファクターでセキュリティを高めようとしても、ユーザーの不満や安全でない回避策を招くだけで、43%の組織が多要素認証（MFA）の使用における最大の障害としてユーザーエクスペリエンスを挙げています。 ハイブリッドワークやリモートワークへの移行は、今日のID管理やアクセス管理の方法における弱点を増大させています。 IDアクセス管理(IAM)、および特権アクセス管理(PAM)ソリューションを使用して、エンタープライズアプリケーションへのアクセス制御の合理化が試みられてきました。多くの場合、シングルサインオン (SSO) を使用して、ユーザーがアクセスできるアプリケーションごとに個別のトークンを割り当てます。 IAMやPAMのソリューションの中には、リスク分析を適用してステップアップ認証を促すものもありますが、これは継続的な認証の本質を捉えていません。 さらに、前述のソリューションは、特に設定されていないアプリケーションを監視、接続、操作することができないため、独自の壁によって制限されることが多く、脅威や異常を検出できる高度な自動化機能やインテリジェンスによって、IDとアクセスを管理するための全体的なキャパが減少します。 継続的な認証の概念は、かなり前から存在しており、2004年には、温度、目の動き、クリック圧を測定するさまざまな方法が研究され、80%以上の精度で本人確認を継続的に認証することができました。 今日、コンテキストや行動データにインテリジェンスを適用し、プロセスや認証フレームワークと組み合わせて動的にアクセス制御を適用できるポイントソリューションがいくつか存在します。 ただし、IDまたはアクセスを管理する方法では、基になる信頼モデルにユーザー名やパスワードなどの従来の認証方法やモバイルベースの認証システムが含まれている場合、IDベースライン (本人であることの証明) には本質的に欠陥があります。 実際には、継続的な認証の概念を実現する前に実行しなければならない重要な手順があります。 継続的な認証の構成要素 最先端で強力な認証は、継続的な認証とゼロトラストの両方に必要な構成要素の一つです。 「決して信頼せず、必ず確認する」のゼロトラストフレームワークでは、組織は、ネットワークまたはデータへのアクセスを許可される前に適切に検証されない限り、ユーザー、パケット、インターフェイス、またはデバイスを信頼してはいけません。 この信頼は、継続的な認証の場合と同様に、リスクシグナルを使用して受動的に確立できますが、最初に強力な認証を使用しバックアップする必要があります。 ただし、MFAのすべての形式が同じではないことに注意してください。 どのような形式のMFAも、何もMFAを使用しないよりは優れていますが、ユーザー名とパスワード、またはSMSのワンタイムパスコード (OTP) 、プッシュ通知、認証アプリなどのあらゆるモバイルベースの認証は、フィッシング、標的型攻撃、アカウントの乗っ取りに対して脆弱です。 これらの認証は、マルウェア、中間者 (MiTM) 攻撃、SIMスワップ、およびその他の悪意のある行為によって侵害される可能性のある 「共有シークレット」 に依存しています。  Yubicoは、FIDO2などの最先端規格に支えられた強力な認証を使用して、個人が本人であることを確認するように求める、将来のゼロトラスト戦略のより進化した状態として継続的認証をとらえています。 インテリジェントなシステムが個人のパターンを学習するため、ユーザーはより頻繁に本人確認を求められるようになります。時間の経過とともに、日常的な活動では認証プロンプトの数が減少し、不規則な活動や潜在的にリスクの高い活動時に特権アクセスを行うには、引き続きステップアップ認証が必要になります。 これに備えるために、組織は少なくともフィッシング対策 の2要素認証 (2FA) またはMFAのベースラインを確立する必要があります。これには、単純なタッチや生体認証に依存するYubiKeyなどのハードウェアベースの認証が含まれます。 理想的なのは、組織がユーザーフレンドリでパスワード不要の強力な認証に移行した場合にのみ、ゼロトラストと継続的な認証フレームワークを構築できるようになることです。 現在、すべてのシステムとアプリケーションに継続的な認証を適用できる単一の解決策はありません。 しかし、今日の組織は、認証を向上させ、機密性の高いデータへのアクセスを一般的に提供するミッション・クリティカルなアプリケーションに継続的な認証の概念を適用するよう、行動を起こすことができます。  FIDO U2FやFIDO2などのフィッシング対策認証プロトコルとゼロトラスト原則を使用し、認証フレームワークを将来に備え強化することで、将来のより現代的で応答性の高いセキュリティ戦略の基盤を築くことができます。  — 強力なフィッシング対策認証を使用してゼロトラスト戦略を加速する方法の詳細については、こちらのホワイトペーパーを参照してください。.

企業や組織を見ると、安全な認証に取り組むときに存在し得る多くのビジネスシナリオがあります。 共有ワークステーションであれ、リモートワーカーであれ、特権アカウントであれ、問題となるものは、モバイルデバイスが制限された職場です。 デリケートな仕事を行うため、何らかの方法でモバイルを制限する職場は常に存在すると言っても過言ではありません。 これらの分野では、機密性の高いシステムやデータへのアクセスを許可するためのユーザー認証など、あらゆる目的で電話を使用することはできません。 「モバイル制限付きアクセス」とは、「安全な箱にスマートフォンをしまう」シナリオだけを指すのではありません。 ほとんどの場合、制限は少ないです。例えば、建物の一部のエリアでは電話を使用できますが、他のエリアでは使用できません。 セルラー接続に信頼性がない遠隔地はどうですか？ あるいは、一部の企業向けアプリには電話が使用できるものの、ミッションクリティカルな機能に触れるアプリには使用できない場合があります。 こうした環境はすべて、モバイル認証を困難または完全に使用不可能にします。   この投稿では、最も一般的な制限付きワークスペースについて概要を示し、モバイルデバイスを使用せずにこれを保護する方法について説明します。  一般的なモバイルデバイス制限付きワークスペースの制限付きワークスペース  以下の種類の職場環境では、ユーザーの生産性を損なうことなく強力なセキュリティを実現するために、他のユーザー認証を検討する必要があります： コールセンター – 今日のほぼすべての電話には、カメラと音声録音機能で構成される「スパイパッケージ」が付属しています。 コールセンターでは多くの場合、個人情報（PII）またはその他の機密性の高い顧客情報に自由にアクセスできるため、モバイルデバイスが冗長になりがちです。 工場の作業場 – 産業の現場では、作業者の安全や環境的な制限のためにデバイスが制限されている場合や、その場所で機密データにアクセスできる場合があります。 石油掘削所のような屋外の場所では、標準のスマートフォンによる処理以上に頑丈なデバイスが必要となる場合があります。  高セキュリティ環境 – AAL3やFIPSで検証された認証コードなど、フィッシングに強いハードウェアセキュリティキーを使用する、高い認証保証が要求される職場。 これらは、政府機関や金融サービス会社でよく見られます。 さらに、管理者の認証情報は非常に価値のある標的です。認証情報が侵害されると重大な損害を引き起こす可能性があるため、モバイル認証はおそらく最善の方法ではありません。  研究開発ラボ – 言うまでもなく、最も気密性の高い企業IPが存在する可能性のある場所では、簡単にビデオ録画や写真撮影をしたり、それを公開したりできるモバイルデバイスは存在が許可されません。 ラボでスマートフォンをドアのそばに置いておく必要がある場合は、スマートカードまたはFIDOセキュリティキーを使うほうが良いでしょう。 遠隔ステーション – 気象観測所、観測データポスト、海洋掘削、または信頼できるセルサービスから遠い研究施設のことです。高価な緩和インフラがないと、ほとんどのデバイスは役立ちません。  飛行機– おなじみの場所です。 フライト時間は長く、認証システムへの準拠が不明なネットワークを介してのみ、インターネットに接続できます。 モバイルが機内システムで動作しない場合、空中で多くの時間を過ごす従業員には、代替のMFA認証プロセスが必要です。  組合または政府の規則により制限されるBYODの領域 – 「所有デバイスの持参」規制は、米国内でも、世界中の国々でも一般的になっています。 同規則では、個人デバイスを保証なしで仕事関連のタスクに使用することを許可しません。 企業が仕事専用のモバイルデバイスを用意する意思がない場合、モバイル認証は行えない場合があります。  顧客対応環境 – 特に接客および小売業界の企業は、顧客と対面して最高の体験を提供するよう努めています。  その結果、多くの人がスマートフォンの使用を制限されています。そうしないと、従業員が顧客と十分に関わっていないという認識を生むからです。 上記のモバイル制限に関する考慮事項に加え、フィッシング対策（スマートカードまたはFIDO/WebAuthnベース）のMFAをユーザーに展開する際には、以下の項目が重要です： 共有ワークステーションに適用可能– 多くの場合、これらのステーションはすでに物理的にセキュリティ制御された場所に設置されることが多いですが、より強化するために、ステーション自体にフィッシング対策認証を追加する必要があります。 ワークステーションを柔軟にすることにより、シフトを終了、開始するユーザー間で高速かつ安全なタスク切り替えが可能となります。 接続の必要がない堅牢なデバイス – 堅牢なデバイスは、セルラー接続がないなど、どのような状況でも動作し、オフラインまたはネットワーク接続状況の両方で動作する、さまざまなコンピューターやその他のコンポーネントを保護できます。  簡単なユーザーエクスペリエンス（UX） – ユーザーを忘れずに！ […]

SolarWindsおよびColonial Pipelineにおけるサプライチェーンのセキュリティ侵害は、ソフトウェアへのサプライチェーン攻撃を主流にした2つの（多くの）インシデントです。世界的に、病院および燃料輸送が最近の目標となっています。途中で監視する必要のあるエントリポイントが数千とは言わないまでも、数百はあることを考えると、サプライチェーンの防御は容易ではないということが、企業にとっての主な課題となっています。ただし、ベンダーとデータをやり取りまたは交換するための、十分に計画された戦略と組み合わせれば、サプライチェーン攻撃リスクを軽減するベストプラクティスとなります。  サプライチェーンの広い視野を持つ サプライチェーンには幅広い関係が含まれます。一般に考えられる物理的な商品や構成要素をA地点からB地点に輸送することだけではありません。サプライチェーンには企業が持つ可能性のあるパートナーシップと事業関係も含まれているため、あらゆる企業は、そこに荷札がついていなくても、サプライチェーンを持っています。実際、企業独自の製品またはサービスを開発するために使用される任意の製品（ソフトウェアまたはハードウェア）およびサービスを、サプライチェーンと呼ぶ場合があります。パートナーのシステムと貴社のネットワークにアクセスするシステムが適切に保護されていることを確認して、侵害や停止のリスクを軽減する必要があります。  ソフトウェアをサプライチェーンの一部として考えると、それは貴社のシステムにコードを提出するサードパーティーと協力するソフトウェア開発チームを意味するかもしれません。また、コードベースに統合されているサードパーティーのソースからIT製品またはコードを購入することも意味します。 サプライチェーンの「全体像」を確認したら、ターゲットを絞ったサプライチェーンのセキュリティ目標を設定できます。購入して使用するソフトウェア、他者が開発したコード、使用するサービスなど、取り扱うすべての製品が安全で、優れたセキュリティ対策に従っているようにします。  コード管理 自社開発コードを使用する場合でも、社外で開発されたコードを使用する場合でも、コード管理プロセスが検証されていることが重要です。外部ソースと連携する場合は、信頼性を確保するために署名キーと証明書の安全性を保つことが特に重要です。  ソースコードとソフトウェア製品の管理についての3つの重要な質問があります（先に答えを教えておくと、3つはすべて「はい」でないといけません）。これらの回答を注意深く確認することで、展開後、ソースコードに脆弱性が発生するのを防ぐことができます。 ソースコード管理システム（SCM）はありますか？適切なSCMがあれば、コードバージョンは適切に管理され、システムにログインするすべての人が適切な権限で認証されます。SCMは、コードにタイムスタンプを付けてその動きをログに記録するため、いかなる場合でも悪意ある第三者が検出されずに操作することはなくなります。SCMは、コードに信頼感をもたらすCoCを確立するために、適切に管理される必要があります。  コードコミットとコードは適切に署名されていますか？ 署名は、ソフトウェアドライバ、アプリケーション、インストールファイル、スクリプト、車両や産業用システムのファームウェアモジュールを含む、すべての種類のソフトウェアモジュールと実行可能ファイルを保護するために使用する必要があります。コード署名とコードコミット署名は、SCMシステムに必要な機能である必要があります。システムを導入したら、すべての開発者がコードコミットに署名するように適切に設定します。一例としてGithubでコミットに署名する方法に関する簡単なチュートリアルを参照してみてください。    コンポーネントとその出所を特定するソフトウェアの「部品表」（SBOM）はありますか？開発者が非常に忙しく、利用可能なオープンソースコードが非常に多い場合、コードの出所を知ることが重要です。すべてのオープンソースコードが同じように作成されているわけではなく、攻撃者は既知の脆弱性を利用します。オープンソースコードを使用する場合は、開示する必要があります。オープンソースのコンポーネントを特定することで、自社管理するコードでも、購入したソフトウェアでも、将来発生する可能性のある脆弱性に迅速に対応できるようになります。このような背景から、政府の新しいソフトウェア開発要件では、セキュリティリスクを軽減するために特にSBOMに注目しています。 米国は2022年の来たる規制に備えている 上記の質問のほとんどに詳細な回答ができるなら、米国政府にソフトウェアを提供する企業に向けたバイデン政権の大統領命令に応じて、新しいセキュアソフトウェアサプライチェーンガイドラインを満たす準備をすぐに開始できます。それは、あらゆる形式のコードを不正アクセスや改ざんから保護することを求めています。フィッシングに強いMFAとコードコミットへの署名は、サプライチェーンのセキュリティ体制を改善し、コンプライアンスの要求を満たすための重要なセキュリティ制御です。使用するコンポーネントとコードの安全な管理方法をより詳細に把握することで、全体的なセキュリティは向上し、ユーザーからの信頼が向上します。