クラウドID管理のリスクと課題「特権アカウントのベストプラクティス」

特権アカウントは標準アカウントよりも適切に保護する必要があり、特権アカウント管理(PAM:Privileged Access Management)では、すべての特権アカウントを管理するための厳格な計画とITインフラストラクチャを必要とします。

「特権アカウントの概要」については、こちらを参照ください。
→Keyspider.jp →クラウドID管理のリスクと課題「特権アカウントの概要」

「データ侵害の74%は特権アカウントへのアクセスに関係している」というデータもあります。

今回は、特権アカウント管理を確実に実施するためのベストプラクティスを紹介します。

主なベストプラクティス

確実な特権アカウント検出プロセスを確立

重要データにアクセスできるアカウントを指定するためには、オンプレミスとクラウドの両方で、すべての特権アクセスを識別する必要があります。

これには「個人アカウント」「共有アカウント」「ローカル管理者アカウント」「ドメイン管理者アカウント」などのすべてが含まれます。

システムやアカウントは常に更新されているため、継続的プロセスを確立することが重要です。

特権アカウント用パスワード保護ポリシーの導入

「不正アクセス防止」「規制準拠実証」のために、特権アカウント用パスワード保護ポリシーを導入します。

特権アカウントを使用および管理するすべての人が理解して受け入れることができる明確なポリシーを作成することが重要となります。

強力なパスワードは基本的なサイバーセキュリティ要件ですが、パスワードを定期的に変更し、パスワード管理のベストプラクティスに従う必要があります。決して共有されてはいけません。

パスワードだけではなく、生体認証を加えた多要素認証によるセキュリティ強化も必要です。

最小特権を実装

攻撃者が機密データにアクセスするリスクを減らすために、ユーザーには仕事をするために必要な最低限の特権のみを与えます。

特権アカウントは適切な担当者にのみ付与しますが、必要に応じて職務と特権を分離して割り当てる必要があります。

職務と特権を分離することで、担当者によるセキュリティ違反を防ぎ、インシデント調査ログの整合性を確保できます。

特権アクティビティの監視と監査

特権アカウントに対する脅威の1つとして「正当な特権アクセスを持つ担当者による組織内からの侵害」があります。

この脅威を防ぎ軽減するために、特権セッション監視機能を実装して、疑わしい特権アクティビティを監視する必要があります。

特権ユーザー行動分析ソリューションは、「ユーザーアクティビティ」「アカウント行動」「アクセス行動」「資格情報の機密性」「ユーザー行動を考慮した機械学習アルゴリズムに基づく行動ベースライン」などを使用して、特権アクティビティに関する洞察を得るのに役立ちます。

その結果、推奨ガイドラインからの逸脱を検出し、潜在的攻撃開始前に防げる可能性が高まります。

また、特権アクティビティの監視と記録に加えて、キーストロークとスクリーンショットをキャプチャして、すべてのアクティビティを監査する場合もあります。

適切なPAMソリューションを選択

適切なPAMソリューションを導入することで、専門的なセキュリティ評価が可能となります。

特権アカウントが保護しているものを特定し、「セキュリティポリシー」「制御」「プロセス」を客観的に詳細化することにより、一定のレベルまでセキュリティを向上できます。

特権アカウントの「包括的可視性確立」「適切なポリシー制定」「最小限特権実装」「厳格なアクティビティ監視」などが実施されることで、特権アカウントの悪用を防ぎ、組織内外のセキュリティリスクに対して効果的に取り組むことができます。

スタッフトレーニング

多くの場合、エンドユーザーのセキュリティリテラシーが、ITシステムにおいて最も弱い部分となります。

これは、迫り来る脅威を知らず、ハッカーから身を守る方法を理解していないためです。

そのため、アカウントを保護するために必要な情報を提供し、サイバーセキュリティ慣行の重要性についてスタッフと話し合うことが重要となります。

ID管理クラウドサービス「Keyspider」とは?

Keyspiderサイト「keyspider.jp」では、Keyspiderに関する情報を紹介しています。

「概要説明」「コンセプト」「他サービス連携」「主要機能」「マネージドサービス」などについて参照できますので、ご興味のある方はご確認ください。


参考元サイト

クラウドID管理のリスクと課題「特権アカウントの概要」

アカウントの種類

①非特権アカウント

最小権限の原則により、ほとんどのユーザーは90%以上の時間、非特権アカウントで操作しています。

最小特権アカウント(LUA:Least-privileged User Account)とも呼ばれる非特権アカウントは、次の2つのタイプで構成されます。

標準ユーザーアカウント

標準ユーザーアカウントは、「インターネット接続」「オフィスアプリケーション」などの通常業務で最低限度必要なアクセスが許可されます。

ロールベースアクセスポリシーによって定義される「限られたリソースへのアクセス」など、制限された一部特権も保有します。

ゲストユーザーアカウント

ゲストユーザーアカウントは、通常、「インターネット接続」と「基本的なアプリケーションアクセス」のみに制限されているため、標準ユーザーアカウントよりも、さらに特権が少なくなります。

②特権アカウント

特権アカウントは、「スーパーユーザーアカウント」とも呼ばれる特別な種類のアカウントです。

管理用アカウントとして「非特権アカウントの制限を超えてのアクセス」と「最大級の権限」が付与されます。

「特権アカウント」とは

概要

特権アカウント(スーパーユーザーアカウント)は、主に専門のITスタッフによる管理に使用され、コマンドを実行してシステムを変更するためなどに使用されます。

実質的に無制限の権限を有しています。

OS別特権アカウント(スーパーユーザーアカウント)

UNIX(Linux)

UNIX(Linux)でのスーパーユーザーアカウントは「root」と呼ばれます。

自己システムを破壊できるほどの最大権限を有しています。

Windows

Windowsでのスーパーユーザーアカウントは「Administrator」と呼ばれます。

Windowsシステムでは、各Windowsコンピューターに少なくとも1つの管理者アカウントがあります。

ユーザーは管理者アカウントを使用することで、「ソフトウェアインストール」や「ローカル構成設定」などの操作を実行できます。

権限

・「ファイル」「ディレクトリ」「リソース」への無制限アクセス
・完全な「読み取り権限」「書き込み権限」「実行権限」
・ソフトウェアインストール
・完全なシステム変更権限
・ネットワーク全体に体系的な変更をレンダリングする権限 など

リスク

特権アカウントは、非特権アカウントよりも大幅に強力な権限による操作が許可されているため、非常に大きなリスクをもたらす危険性があります。

「操作ミス」「悪意のある操作」などが発生した場合、「システム完全停止」「機密情報流出」などにより、企業存続にまで影響を与える可能性があります。

そのため、特権アカウント管理は、ID管理の中でも最も重点的に管理しなければならない対象とされています。

「特権アカウント」の例

ローカル管理アカウント(システムアカウント)

ローカル管理アカウント(システムアカウント)は、ローカルホスト(インスタンス)のみへの管理アクセスが許可される非個人アカウントです。

主として、メンテナンスを実行するためにITスタッフによって日常的に使用されます。

ドメイン管理アカウント

ドメイン管理アカウントは、ドメイン内のすべてのサーバに対する特権的管理アクセスが許可されます。

ネットワーク全体で広範囲なアクセスを提供します。

緊急アカウント

緊急アカウントは、緊急時に、特権のないユーザーに対して安全なシステムへの管理アクセスを提供します。

「Firecall」または「Breakglass」アカウントと呼ばれることもあります。

サービスアカウント

サービスアカウントは、アプリケーション(サービス)がOSと対話するために使用する特権アカウントです。

アプリケーションアカウント

アプリケーションアカウントは、アプリケーションが「データベースアクセス」「バッチジョブ実行」「スクリプト実行」「他アプリケーションへのアクセス」などを実行するために使用するアカウントです。

ID管理クラウドサービス「Keyspider」とは?

Keyspiderサイト「keyspider.jp」では、Keyspiderに関する情報を紹介しています。

「概要説明」「コンセプト」「他サービス連携」「主要機能」「マネージドサービス」などについて参照できますので、ご興味のある方はご確認ください。


参考元サイト

クラウドID管理における「IDライフサイクル管理」

「IDライフサイクル管理」とは

IDライフサイクル管理(ILM:Identity Lifecycle Management)とは、ユーザーIDの「作成」「更新」「削除」などの継続的かつ適切なメンテナンスアクションの実行を指します。

IDライフサイクル管理は、エンドユーザーがアクセスするすべてのアプリケーション(サービス)に直接結びついているため、IAM戦略全体の中でも非常に重要とされています。

「IDライフサイクル管理」の目標

IDライフサイクル管理の目標は「組織環境全体におけるIDプロセスの自動化」にあります。

自動化により、組織内の異種システム全体において、IDが信頼できるソースと一致する状態になります。

ILMエンジンがなく自動化できていない状態では、IDの変更を手動で処理および管理し、適切なアクションを確実に実行しなければならないため、維持管理は非常に困難となります。

「IDライフサイクル管理」の自動化レベル

「IDライフサイクル管理」の自動化レベルについては、以下のように、おおまかに5段階でレベル設定されています。

レベル0:手動

レベル0は「アカウントのプロビジョニングは完全に手動」「アドホックベースまたは事後対応ベースで完了」の段階です。

各ユーザーアカウントは個別に手動で処理されるため、アカウントデータには人為的エラーが発生しやすくなります。

新入社員入社などの時期には、大量の手動処理が発生するために、多くの時間とコストが必要となります。

レベル1:スクリプトベース

レベル1は「スクリプトベースによる一部自動化」の段階です。

この段階では、アドホックリクエストを解決するために、システム単位でスクリプトが作成され運用されるケースが多いため、システム間連携のためのスクリプトも必要となります。

また、組織内の他部門では、別スクリプトによる異なる運用が実施されているため、全社レベルの完全性は低いものとなります。

レベル2:オンボーディング自動化

レベル2は「オンボーディング自動化」の段階です。

ベンダー提供のツールなどを利用して、オンボーディング(プロビジョニング)を実施することで、新しいユーザーアカウントを作成します。

ただし、この段階では、ユーザーが組織を離れた場合の「ID削除処理」や「部門間異動処理」などの機能はありません。

レベル3:IDロジックエンジン

レベル3は「IDロジックエンジン」の段階です。

このレベルでは、すべてのILM機能を一元化し、IDオンボーディングだけではなく、多数イベントで構成されるライフサイクルプロセス全体を統合的に管理できるIDロジックエンジンを利用できます。

そのため、ユーザーが組織を離れた場合には、IDは簡単に削除できます。

また、どのユーザーがどのアプリケーションやリソースにアクセスできるかを示せるため、監査プロセスが簡素化されます。

レベル4:API駆動型ILM

レベル4は「API駆動型ILM」の段階です。

これは、既存システムが新しいシステムにID情報をプッシュする方法を設計する必要がなく、新しいシステムがAPIでID情報を取得します。

RESTfulAPIを提供することは、システム間の統合またはデータ同期を可能にするための事実上の標準になりつつあります。

ILM実装の複雑さを軽減するために、業界がAPI主導の方向に向かっていることを示す多くの標準が公開されています。

「IDライフサイクル管理」における主な課題

①IDデータ設計

IDデータ設計の課題としては以下のようなものがあります。

・ユーザー情報について信頼できるソースは何か?
・複数ソースがある場合、それらの間でデータを同期するにはどうすればよいか?
・どのようにして一意の「ユーザー名」と「メールアドレス」を作成するか? など

②アドホック手動ID処理タスク

ITチームは、以下の理由で、手動IDタスクによって頻繁に圧迫されます。

・アプリ所有者やビジネスユニット管理者が「誰からのアクセスを許可するか?」を決定する
・各部門で高度にカスタマイズされたビジネスロジックを実装している など

③アクセス許可管理

リモート作業環境の大幅増加が、新しいデジタルコラボレーションリソースの需要を押し上げていることにより、従来にはなかったアクセス許可に関するタスクが増大しています。

ID管理クラウドサービス「Keyspider」とは?

Keyspiderサイト「keyspider.jp」では、Keyspiderに関する情報を紹介しています。

「概要説明」「コンセプト」「他サービス連携」「主要機能」「マネージドサービス」などについて参照できますので、ご興味のある方はご確認ください。


参考元サイト

クラウドID管理のセキュリティ「ゼロトラストセキュリティ」

「ゼロトラストセキュリティ」とは

「絶対に信頼しない」セキュリティアプローチ

ゼロトラストセキュリティとは「絶対に信頼しない」というセキュリティアプローチです。

すべてのアクセス試行を、信頼できない「ネットワーク」「デバイス」「ユーザーアカウント」から発信されているものとして扱い、信頼が実証されるまでアクセスは許可されません。

そのため、ゼロトラストセキュリティでは、エンタープライズネットワーク内のユーザーを含むすべてのユーザーアカウントに対して、セキュリティ状態の常時継続的検証が要求されます。

ゼロトラストセキュリティアプローチは、組織が「ネットワーク」「アプリケーション」「データ」へのアクセスを制御するための効果的な方法の1つとして注目されています。

従来型アプローチとの違い

従来型セキュリティアプローチ

従来の「境界ネットワークセキュリティアプローチ」では、ファイアウォールなどの設置により攻撃者をネットワークから遠ざけることに重点を置いており、『エンタープライズネットワーク内のリソースは信頼できる』ことを前提としています。

しかし、リモートワークの普及などにより、この仮定はもはや当てはまらない状況になっています。

ゼロトラストセキュリティアプローチ

ゼロトラストセキュリティでは「ネットワークは侵害されている状態である」と想定し、ユーザー(デバイス)に対して「攻撃者ではない」ことを証明するように要求し、厳密なID検証を実施します。

ユーザー(デバイス)が適切な権限と属性を有していた場合のみアクセスを許可しますが、ユーザー属性や脅威は変更される可能性があるため、最初の1回限りのID検証では不十分です。

常時継続的なID検証が実施され、正当性がなくなるとアクセス拒否となります。

ゼロトラストセキュリティモデルの原則

①信頼できるソースは存在しない

ゼロトラストセキュリティモデルでは「信頼できるソースは存在しない」「攻撃者となりうるユーザーアカウントが潜んでいる」という前提となります。

②各種セキュリティ技術の統合活用

ゼロトラストセキュリティモデルでは、さまざまなセキュリティ技術を統合的に組み合わせて活用することで、ユーザーアカウントを検証し、システムのセキュリティを維持します。

・ID管理
・最小特権制御アプローチ
・多要素認証
・エンドポイントセキュリティ
・マイクロセグメンテーション
・クラウド統合 など

③リアルタイム監視

ゼロトラストセキュリティモデルは本質的に大部分が予防的アプローチですが、ブレイクアウトタイムを最小化するために、リアルタイム監視機能も組み込む必要があります。

ブレイクアウトタイムとは、「侵入者が最初のマシンを侵害してから他システムに侵攻している時間」であり、1秒でも早く発見して対処しなければなりません。

主なリアルタイム監視対象

・ユーザーID
・エンドポイントハードウェアタイプ
・ファームウェアバージョン
・OSバージョン
・パッチレベル
・アプリケーション
・ユーザーログイン状況
・セキュリティステータス
・インシデント検出 など

④包括的セキュリティ戦略との統合

ゼロトラストセキュリティモデルは「包括的セキュリティ戦略における一部」にすぎません。

デジタルセキュリティ技術は企業を保護するために重要な役割を果たしますが、デジタルだけでは侵害を防ぐことはできません。

企業は、ネットワークセキュリティを確保し、潜在的な攻撃を封じ込め、侵害が発生した場合の影響を最小限に抑えるために、「すべてのエンドポイントに対する常時監視」「ネットワーク構造評価」「アクセス権限評価」などを含む包括的なセキュリティ戦略を採用する必要があります。

ID管理クラウドサービス「Keyspider」とは?

Keyspiderサイト「keyspider.jp」では、Keyspiderに関する情報を紹介しています。

「概要説明」「コンセプト」「他サービス連携」「主要機能」「マネージドサービス」などについて参照できますので、ご興味のある方はご確認ください。


参考元サイト