権限認証機能の比較

多くのコンピュータオペレーティング システムでは、悪意のあるソフトウェアが十分な権限を取得してコンピュータ システムを侵害するのを防ぐためのセキュリティ機能を採用しています。DOS、Windows NT (およびその派生製品)より前のWindows実装、CP/M-80、Mac OS X より前のすべての Mac オペレーティング システムなど、こうした機能を持たないオペレーティング システムでは、何でも実行できるユーザーのカテゴリは 1 つだけでした。実行コンテキストを分離することで、複数のユーザーがプライベート ファイルを格納したり、複数のユーザーが同時にコンピュータを使用したり、悪意のあるユーザーからシステムを保護し、悪意のあるプログラムからシステムを保護したりすることが可能です。最初のマルチユーザー セキュア システムはMulticsで、1960 年代に開発が始まりました。マルチタスク セキュリティ コンテキストがx86コンシューマー マシンに導入されたのは、80 年代後半から 90 年代前半のUNIX、BSD、Linux、およびNTになってからでした。

マイクロソフトウィンドウズ

macOS

UnixおよびUnixライク

セキュリティ上の主要な考慮事項は、悪意のあるアプリケーションがキーストロークやマウスのクリックをシミュレートし、セキュリティ機能を 騙したり偽装したりして、悪意のあるアプリケーションに高い権限を付与する能力です。

• ターミナルベースのクライアント (スタンドアロンまたはデスクトップ/GUI 内) の使用: suとsudo はターミナルで実行されるため、偽装された入力に対して脆弱です。もちろん、ユーザーがマルチタスク環境を実行していない場合 (つまり、シェル内の 1 人のユーザーのみ)、これは問題になりません。ターミナル ウィンドウは通常、ユーザーに対して通常のウィンドウとしてレンダリングされるため、クライアントとして使用されるインテリジェント クライアントまたはデスクトップ システムでは、デスクトップ上の他のマルウェアが入力を操作、シミュレート、またはキャプチャするのを防ぐ責任はユーザーにあります。
• オペレーティング システムに緊密に統合された GUI/デスクトップを使用する:通常、デスクトップ システムは、パスワードやその他の認証を要求する前に、すべての一般的な入力手段をロックまたは保護して、傍受、操作、またはシミュレートできないようにします。

• PolicyKit ( GNOME - Xサーバーにすべてのキーボードとマウスの入力をキャプチャするように指示します。PolicyKit を使用する他のデスクトップ環境では、独自のメカニズムが使用される場合があります。
• gksudo - デフォルトではキーボード、マウス、ウィンドウのフォーカスを「ロック」し、^[12]実際のユーザー以外がパスワードを入力したり、確認ダイアログに干渉したりすることを防ぎます。
• UAC (Windows) - デフォルトではセキュアデスクトップで実行され、悪意のあるアプリケーションが「許可」ボタンのクリックをシミュレートしたり、確認ダイアログを妨害したりするのを防ぎます。^[13] このモードでは、ユーザーのデスクトップは暗く表示され、操作できません。

gksudo の「ロック」機能または UAC の Secure Desktop のいずれかが侵害されたり無効になったりすると、悪意のあるアプリケーションがキーストローク ログを使用して管理者のパスワードを記録し、管理者権限を取得できる可能性があります。または、UAC の場合は管理者として実行され、「許可」ボタンのマウス クリックを偽装できます。このため、音声認識もダイアログとの対話を禁止されています。^{[引用が必要] gksu パスワード プロンプトは特別な権限なしで実行されるため、悪意のあるアプリケーションは、たとえば}straceツールを使用してキーストローク ログを実行できます。^[14] (ptrace は、後のカーネル バージョンで制限されました) ^[15]

セキュリティに関するもう 1 つの考慮事項は、悪意のあるソフトウェアが、正当なセキュリティ確認要求のように見えるダイアログを偽装する能力です。ユーザーが偽のダイアログを正当なものだと思って資格情報を入力した場合、悪意のあるソフトウェアはユーザーのパスワードを知ることができます。セキュア デスクトップまたは同様の機能が無効になっている場合、悪意のあるソフトウェアはそのパスワードを使用してより高い権限を取得する可能性があります。

• ユーザビリティ上の理由からデフォルトの動作ではありませんが、UAC は、認証プロセスの一環として、ユーザーにCtrl+Alt+Del キー(セキュア アテンション シーケンスと呼ばれる) を押すことを要求するように構成できます。このキーの組み合わせを検出できるのは Windows だけなので、この追加のセキュリティ対策を要求することで、偽装されたダイアログが正当なダイアログと同じように動作することを防ぐことができます。^[16]たとえば、偽装されたダイアログでは、ユーザーに Ctrl+Alt+Del キーを押すように要求されない場合があり、ユーザーはそのダイアログが偽物だと気付く可能性があります。または、ユーザーが Ctrl+Alt+Del キーを押したときに、UAC 確認ダイアログではなく、Ctrl+Alt+Del で通常表示される画面が表示されます。したがって、ユーザーは、そのダイアログが悪意のあるソフトウェアにパスワードを入力するように誘導する試みであるかどうかを判断できます。
• GNOMEでは、PolicyKitはシステムの構成に応じて異なるダイアログを使用します。たとえば、指紋リーダーを備えたシステムの認証ダイアログは、指紋リーダーを備えていないシステムの認証ダイアログとは異なる場合があります。アプリケーションはPolicyKitの構成にアクセスできないため、どのダイアログが表示されるかを知る方法がなく、したがってそれを偽装する方法もありません。^[17]

これらの実装で考慮されたもう 1 つの点は、使いやすさです。

• su では、ユーザーは少なくとも 2 つのアカウント (通常使用アカウントと、rootなどのより高い権限を持つアカウント) のパスワードを知っている必要があります。
• sudo、kdesu、gksudo はよりシンプルなアプローチを使用します。これらのプログラムでは、ユーザーは特定の管理タスクへのアクセスが許可されるように事前に構成されていますが、それらの権限でアプリケーションを実行するには明示的に承認する必要があります。ユーザーはスーパーユーザーまたは他のアカウントのパスワードではなく、自分のパスワードを入力します。
• UACとAuthenticate は、これら 2 つのアイデアを 1 つに組み合わせたものです。これらのプログラムを使用すると、管理者はより高い権限でプログラムを実行することを明示的に承認します。管理者以外のユーザーには、管理者のユーザー名とパスワードの入力が求められます。
• PolicyKit は、これらのいずれかのアプローチを採用するように構成できます。実際には、ディストリビューションは 1 つを選択します。

• アプリケーションに管理者権限を付与するために、sudo、^[18] gksudo、Authenticateは管理者にパスワードの再入力を要求します。
• UACでは、標準ユーザーとしてログインすると、アプリケーションに管理者権限を付与する必要があるたびに、ユーザーは管理者の名前とパスワードを入力する必要があります。しかし、Administrators グループのメンバーとしてログインすると、毎回パスワードを再入力するのではなく (既定では) 単に確認または拒否するだけで済みます (ただし、これはオプションです)。既定の方法は簡単ですが、安全性も低くなります。^[16]ユーザーがコンピューターをロックせずに物理的に離れると、別の人が近づいてシステムの管理者権限を取得できるためです。
• PolicyKit では、ユーザーはパスワードを再入力するか、他の認証手段 (指紋など) を提供する必要があります。

• UAC は、プログラムを昇格するために呼び出されるたびに、承認を求めます。
• sudo、^[6] gksudo、kdesuは、プログラムを昇格するために呼び出されるたびに、ユーザーにパスワードの再入力を求めません。代わりに、ユーザーは起動時に一度パスワードを求められます。ユーザーが一定時間（sudoのデフォルトは5分^[6]）管理者権限を使用しなかった場合、ユーザーは再びパスワードを入力するまで標準ユーザー権限に制限されます。

sudo のアプローチは、セキュリティと使いやすさのトレードオフです。一方では、一連の管理者タスクを実行するために、ユーザーはパスワードを 1 回入力するだけで済みます。タスクごとにパスワードを入力する必要はありません。しかし同時に、タイムアウト前にこれらのコマンドのいずれかがプレフィックスとして付いた、その tty で実行されるすべてのプログラム (sudo の場合) またはターミナルで実行されていないすべてのプログラム (gksudo および kdesu の場合) が管理者権限を取得するため、攻撃を受ける可能性が高くなります。セキュリティを重視するユーザーは、sudo -ksudo が使用された各 tty または pts から when コマンドを使用して、管理者権限を必要とするタスクを完了したら、一時的な管理者権限を削除できます (pts の場合、ターミナル エミュレーターを閉じるだけでは不十分です)。kdesu の同等のコマンドは ですkdesu -s。同じことを行う gksudo オプションはありませんが、sudo -kターミナル インスタンス内以外で実行すると (たとえば、Alt + F2 の [アプリケーションの実行] ダイアログ ボックスで [ターミナルで実行] のチェックを外す)、目的の効果が得られます。

• 認証ではパスワードは保存されません。ユーザーが標準ユーザーの場合は、ユーザー名とパスワードを入力する必要があります。ユーザーが管理者の場合は、現在のユーザーの名前がす​​でに入力されているため、パスワードを入力するだけです。名前を変更して別のユーザーとして実行することもできます。

アプリケーションは一度だけ認証を必要とし、アプリケーションが権限を必要とするときに要求されます。一度「昇格」されると、アプリケーションが終了して再起動されるまで、アプリケーションは再度認証する必要がありません。

ただし、認証にはさまざまなレベルがあり、権限と呼ばれます。要求された権限は、パスワードの下の「詳細」の横にある三角形を展開すると表示されます。通常、アプリケーションは system.privilege.admin を使用しますが、セキュリティのために低い権限を使用したり、より高いアクセスが必要な場合は高い権限を使用したりすることもできます。アプリケーションが持つ権限がタスクに適していない場合、権限レベルを上げるためにアプリケーションを再度認証する必要がある場合があります。

• PolicyKit は、これらのいずれかのアプローチを採用するように構成できます。

オペレーティング システムがユーザーに承認を求めるタイミングを認識するには、アプリケーションまたはアクションが、昇格された権限が必要であることを自ら認識する必要があります。技術的には、そのような権限を必要とする操作が実行される瞬間にユーザーにプロンプ​​トを表示することは可能ですが、タスクの完了の途中で権限を求めるのは理想的ではないことがよくあります。ユーザーが適切な資格情報を提供できない場合、タスクを最後まで実行できないため、管理者権限を要求する前に行われた作業を取り消す必要があります。

Microsoft Windows のコントロール パネルや Mac OS X の環境設定パネルなどのユーザー インターフェイスの場合、正確な権限要件がシステムにハードコードされているため、適切なタイミングで (たとえば、管理者だけが表示できる情報を表示する前など) ユーザーに認証ダイアログが表示されます。オペレーティング システムごとに、アプリケーションがセキュリティ要件を識別するための異なる方法が提供されています。

• sudo は、すべての権限承認情報を 1 つの構成ファイルに集中管理します。/etc/sudoersこの構成ファイルには、ユーザーのリストと、それらのユーザーが使用できる権限付きアプリケーションおよびアクションが含まれています。sudoers ファイルの文法は、コマンドライン パラメータに制限を設けるなど、さまざまなシナリオに対応できる柔軟性を備えています。たとえば、次のように、ユーザーには、ルート アカウント以外のすべてのユーザーのパスワードを変更するアクセス権を付与できます。

pete ALL = /usr/bin/passwd [Az]*, !/usr/bin/passwd ルート

• ユーザー アカウント制御は、ヒューリスティック スキャンと「アプリケーション マニフェスト」を組み合わせて、アプリケーションに管理者権限が必要かどうかを判断します。^[19] マニフェスト ( .manifest ) ファイルは、Windows XP で初めて導入されたもので、アプリケーションと同じ名前に「.manifest」というサフィックスが付いたXMLNotepad.exe.manifestファイルです (例: ) 。アプリケーションが起動されると、マニフェストを参照して、アプリケーションのセキュリティ要件に関する情報が調べられます。たとえば、次の XML フラグメントは、アプリケーションに管理者アクセスが必要であるが、アプリケーション外部のユーザー デスクトップの他の部分への自由なアクセスは必要ではないことを示しています。

<security> 
<requestedPrivileges> <requestedExecutionLevel level= "requireAdministrator" uiAccess= "false" /> </requestedPrivileges> </security>    
           
    

マニフェストファイルは、埋め込みリソースとしてアプリケーション実行ファイル自体にコンパイルすることもできます。ヒューリスティックスキャンも、主に下位互換性のために使用されています。その一例は、実行ファイルのファイル名を確認することです。ファイル名に「Setup」という単語が含まれている場合、実行ファイルはインストーラーであると想定され、アプリケーションの起動前にUACプロンプトが表示されます。^[20]

UAC は、署名された実行ファイルと署名されていない実行ファイルからの昇格要求を区別し、前者の場合は発行元が「Windows Vista」であるかどうかを区別します。プロンプトの色、アイコン、および文言はそれぞれの場合で異なります。たとえば、実行ファイルが署名されていない場合は、署名されていない場合よりも強い警告を伝えようとします。^[21]

• PolicyKitを使用するアプリケーションは、認証を求める際に特定の権限を要求し、PolicyKit はアプリケーションに代わってそれらのアクションを実行します。認証する前に、ユーザーはどのアプリケーションがアクションを要求したか、どのアクションが要求されたかを確認できます。

• 権限昇格、セ​​キュリティエクスプロイトの一種
• 最小権限の原則、セキュリティ設計パターン
• 特権ID管理、特権アカウントを管理する方法論
• 特権パスワード管理は、特権 ID 管理に似た概念です。
  • すなわち、特権パスワードを定期的に暗号化する。
  • パスワード値を安全で可用性の高い金庫に保存する。
  • これらのパスワードをいつ、どのように、誰に開示するかに関するポリシーを適用します。