セキュリティの基本概念Key Security Concepts

Microsoft .NET Framework では、モバイル コードに関するセキュリティへの対応を支援し、各ユーザーにどのような権限を与えるかをコンポーネントで決定できるようにするためのサポートを提供するロールベースのセキュリティがあります。The Microsoft .NET Framework offers role-based security to help address security concerns about mobile code and to provide support that enables components to determine what users are authorized to do.

タイプ セーフとセキュリティType safety and security

タイプ セーフなコードは、アクセス権限を与えられているメモリ位置にだけアクセスします。Type-safe code accesses only the memory locations it is authorized to access. (この説明では、タイプ セーフとは、特にメモリ タイプ セーフを意味し、より広い範囲でタイプ セーフと混同しないでください。たとえば、タイプ セーフなコードでは、別のオブジェクトのプライベート フィールドから値を読み取ることはできません。(For this discussion, type safety specifically refers to memory type safety and should not be confused with type safety in a broader respect.) For example, type-safe code cannot read values from another object's private fields. 適切に定義された許容される方法でだけ、タイプにアクセスします。It accesses types only in well-defined, allowable ways.

ジャスト イン タイム (JIT: Just-In-Time) コンパイル時に、オプションの検査プロセスは、ネイティブなマシン コードに JIT コンパイルされるメソッドのメタデータと Microsoft Intermediate Language (MSIL) を調べて、タイプ セーフかどうかを確認します。During just-in-time (JIT) compilation, an optional verification process examines the metadata and Microsoft intermediate language (MSIL) of a method to be JIT-compiled into native machine code to verify that they are type safe. コードに検査を省略するためのアクセス許可がある場合、このプロセスは省略されます。This process is skipped if the code has permission to bypass verification. 検査の詳細については、「マネージド実行プロセス」を参照してください。For more information about verification, see Managed Execution Process.

タイプ セーフの検査はマネージド コードの実行に必須ではありませんが、アセンブリの分離とセキュリティの適用において、タイプ セーフであることが重要な意味を持ちます。Although verification of type safety is not mandatory to run managed code, type safety plays a crucial role in assembly isolation and security enforcement. コードがタイプ セーフであると、共通言語ランタイムはアセンブリを互いに完全に分離できます。When code is type safe, the common language runtime can completely isolate assemblies from each other. アセンブリが互いに分離していると、アセンブリどうしが悪い影響を及ぼしあうことがなく、アプリケーションの信頼性が向上します。This isolation helps ensure that assemblies cannot adversely affect each other and it increases application reliability. タイプ セーフなコンポーネントは、信頼されるレベルが異なっていても、同じプロセスで安全に実行できます。Type-safe components can execute safely in the same process even if they are trusted at different levels. コードがタイプ セーフでないと、望ましくない副作用が生じることがあります。When code is not type safe, unwanted side effects can occur. たとえば、ランタイムは、マネージド コードがネイティブ (アンマネージ) コードにアクセスしたり、不正な操作を実行することを防止できません。For example, the runtime cannot prevent managed code from calling into native (unmanaged) code and performing malicious operations. コードがタイプ セーフであると、ランタイムのセキュリティ適用機構によって、必要なアクセス許可を持たないコードがネイティブ コードにアクセスすることはできません。When code is type safe, the runtime's security enforcement mechanism ensures that it does not access native code unless it has permission to do so. タイプ セーフでないすべてのコードは、列挙子メンバー SecurityPermission が渡された SkipVerification を与えられていないと実行できません。All code that is not type safe must have been granted SecurityPermission with the passed enum member SkipVerification to run.

詳しくは、「コード アクセス セキュリティの基礎」をご覧ください。For more information, see Code Access Security Basics.

プリンシパルPrincipal

プリンシパルは、ユーザーの ID とロールを表し、ユーザーの代わりを務めます。A principal represents the identity and role of a user and acts on the user's behalf. .NET Framework のロール ベース セキュリティでは、次の 3 種類のプリンシパルがサポートされています。Role-based security in the .NET Framework supports three kinds of principals:

  • 汎用プリンシパルは、Windows のユーザーとロールとは無関係に存在するユーザーとロールを表します。Generic principals represent users and roles that exist independent of Windows users and roles.

  • Windows プリンシパルは、Windows のユーザーとそのロール (または Windows グループ) を表します。Windows principals represent Windows users and their roles (or their Windows groups). Windows プリンシパルは、他のユーザーを偽装できます。つまり、Windows プリンシパルは、あるユーザーに属する ID を提示し、そのユーザーの代わりにリソースにアクセスできます。A Windows principal can impersonate another user, which means that the principal can access a resource on a user's behalf while presenting the identity that belongs to that user.

  • カスタム プリンシパルは、アプリケーションが必要に応じて自由に定義できます。Custom principals can be defined by an application in any way that is needed for that particular application. カスタム プリンシパルによって、プリンシパルの ID とロールの基本概念を拡張できます。They can extend the basic notion of the principal's identity and roles.

詳しくは、「プリンシパル オブジェクトと ID オブジェクト」をご覧ください。For more information, see Principal and Identity Objects.

認証Authentication

認証とは、ユーザーの資格情報を調べ、資格情報をなんらかの権限に対して検証することによって、プリンシパルの身元 を発見および確認するプロセスです。Authentication is the process of discovering and verifying the identity of a principal by examining the user's credentials and validating those credentials against some authority. 認証時に得られる情報は、コードで直接使用できます。The information obtained during authentication is directly usable by your code. また、.NET Framework のロール ベース セキュリティを使用して、現在のユーザーを認証したり、そのプリンシパルにコードへのアクセスを許可するかどうかを判断したりできます。You can also use .NET Framework role-based security to authenticate the current user and to determine whether to allow that principal to access your code. 特定のロールに関してプリンシパルを認証する方法の例については、WindowsPrincipal.IsInRole メソッドのオーバーロードを参照してください。See the overloads of the WindowsPrincipal.IsInRole method for examples of how to authenticate the principal for specific roles. たとえば、WindowsPrincipal.IsInRole(String) オーバーロードを使用すると、現在のユーザーが Administrators グループのメンバーであるかどうかを判断できます。For example, you can use the WindowsPrincipal.IsInRole(String) overload to determine if the current user is a member of the Administrators group.

さまざまな認証メカニズムが現在使用されていて、その多くを .NET Framework のロール ベース セキュリティと一緒に使用できます。A variety of authentication mechanisms are used today, many of which can be used with .NET Framework role-based security. 最も一般に使用されている認証機構としては、基本認証、ダイジェスト認証、パスポート認証、オペレーティング システム認証 (NTLM 認証や Kerberos 認証など)、およびアプリケーション定義の認証機構などがあります。Some of the most commonly used mechanisms are basic, digest, Passport, operating system (such as NTLM or Kerberos), or application-defined mechanisms.

Example

以下の例では、アクティブ プリンシパルが管理者である必要があります。The following example requires that the active principal be an administrator. name パラメーターは null で、これにより、管理者ユーザーがこの確認要求を渡すことを許可されます。The name parameter is null, which allows any user who is an administrator to pass the demand.

注意

Windows Vista では、ユーザー アカウント制御 (UAC: User Account Control) でユーザーの権限が決定されます。In Windows Vista, User Account Control (UAC) determines the privileges of a user. ユーザーが組み込みの Administrators グループのメンバーである場合、そのユーザーには標準ユーザー アクセス トークンおよび管理者アクセス トークンの 2 つのランタイム アクセス トークンが割り当てられています。If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. 既定では、ユーザーは標準ユーザー ロールに所属します。By default, you are in the standard user role. 管理者であることを要求するコードを実行するには、最初に、ユーザーの権限を標準ユーザーから管理者に昇格させる必要があります。To execute the code that requires you to be an administrator, you must first elevate your privileges from standard user to administrator. この操作は、アプリケーションの起動時にアプリケーション アイコンを右クリックし、管理者として実行することを指定して行うことができます。You can do this when you start an application by right-clicking the application icon and indicating that you want to run as an administrator.

using namespace System;
using namespace System::Security;
using namespace System::Security::Permissions;
using namespace System::Security::Policy;
using namespace System::Security::Principal;

int main(array<System::String ^> ^args)
{
    System::String^ null;
    AppDomain::CurrentDomain->SetPrincipalPolicy(PrincipalPolicy::WindowsPrincipal);
    PrincipalPermission^ principalPerm = gcnew PrincipalPermission(null, "Administrators" );
      principalPerm->Demand();
      Console::WriteLine("Demand succeeded");
    return 0;
}
using System;
using System.Threading;
using System.Security.Permissions;
using System.Security.Principal;

class SecurityPrincipalDemo
{

    public static void Main()
    {
        AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
        PrincipalPermission principalPerm = new PrincipalPermission(null, "Administrators");
        principalPerm.Demand();
        Console.WriteLine("Demand succeeded.");
    }
}
Imports System.Threading
Imports System.Security.Permissions
Imports System.Security.Principal



Class SecurityPrincipalDemo


    Public Shared Sub Main()
        AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
        Dim principalPerm As New PrincipalPermission(Nothing, "Administrators")
        principalPerm.Demand()
        Console.WriteLine("Demand succeeded.")

    End Sub
End Class

次の例は、プリンシパルの ID と、プリンシパルで使用できるロールを判別する方法を示しています。The following example demonstrates how to determine the identity of the principal and the roles available to the principal. この例のアプリケーションは、現在のユーザーがアプリケーションの使用を許可するロールに含まれていることを確認できます。An application of this example might be to confirm that the current user is in a role you allow for using your application.

public:
   static void DemonstrateWindowsBuiltInRoleEnum()
   {
      AppDomain^ myDomain = Thread::GetDomain();

      myDomain->SetPrincipalPolicy( PrincipalPolicy::WindowsPrincipal );
      WindowsPrincipal^ myPrincipal = dynamic_cast<WindowsPrincipal^>(Thread::CurrentPrincipal);

      Console::WriteLine( "{0} belongs to: ", myPrincipal->Identity->Name );

      Array^ wbirFields = Enum::GetValues( WindowsBuiltInRole::typeid );

      for each ( Object^ roleName in wbirFields )
      {
         try
         {
            Console::WriteLine( "{0}? {1}.", roleName,
               myPrincipal->IsInRole(  *dynamic_cast<WindowsBuiltInRole^>(roleName) ) );
         }
         catch ( Exception^ ) 
         {
            Console::WriteLine( "{0}: Could not obtain role for this RID.",
               roleName );
         }
      }
   }
using System;
using System.Threading;
using System.Security.Permissions;
using System.Security.Principal;

class SecurityPrincipalDemo
{
    public static void DemonstrateWindowsBuiltInRoleEnum()
    {
        AppDomain myDomain = Thread.GetDomain();

        myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
        WindowsPrincipal myPrincipal = (WindowsPrincipal)Thread.CurrentPrincipal;
        Console.WriteLine("{0} belongs to: ", myPrincipal.Identity.Name.ToString());
        Array wbirFields = Enum.GetValues(typeof(WindowsBuiltInRole));
        foreach (object roleName in wbirFields)
        {
            try
            {
                // Cast the role name to a RID represented by the WindowsBuildInRole value.
                Console.WriteLine("{0}? {1}.", roleName,
                    myPrincipal.IsInRole((WindowsBuiltInRole)roleName));
                Console.WriteLine("The RID for this role is: " + ((int)roleName).ToString());
            }
            catch (Exception)
            {
                Console.WriteLine("{0}: Could not obtain role for this RID.",
                    roleName);
            }
        }
        // Get the role using the string value of the role.
        Console.WriteLine("{0}? {1}.", "Administrators",
            myPrincipal.IsInRole("BUILTIN\\" + "Administrators"));
        Console.WriteLine("{0}? {1}.", "Users",
            myPrincipal.IsInRole("BUILTIN\\" + "Users"));
        // Get the role using the WindowsBuiltInRole enumeration value.
        Console.WriteLine("{0}? {1}.", WindowsBuiltInRole.Administrator,
           myPrincipal.IsInRole(WindowsBuiltInRole.Administrator));
        // Get the role using the WellKnownSidType.
        SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null);
        Console.WriteLine("WellKnownSidType BuiltinAdministratorsSid  {0}? {1}.", sid.Value, myPrincipal.IsInRole(sid));
    }

    public static void Main()
    {
        DemonstrateWindowsBuiltInRoleEnum();
    }
}
Imports System.Threading
Imports System.Security.Permissions
Imports System.Security.Principal

Class SecurityPrincipalDemo

    Public Shared Sub DemonstrateWindowsBuiltInRoleEnum()
        Dim myDomain As AppDomain = Thread.GetDomain()

        myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
        Dim myPrincipal As WindowsPrincipal = CType(Thread.CurrentPrincipal, WindowsPrincipal)
        Console.WriteLine("{0} belongs to: ", myPrincipal.Identity.Name.ToString())
        Dim wbirFields As Array = [Enum].GetValues(GetType(WindowsBuiltInRole))
        Dim roleName As Object
        For Each roleName In wbirFields
            Try
                ' Cast the role name to a RID represented by the WindowsBuildInRole value.
                Console.WriteLine("{0}? {1}.", roleName, myPrincipal.IsInRole(CType(roleName, WindowsBuiltInRole)))
                Console.WriteLine("The RID for this role is: " + Fix(roleName).ToString())

            Catch
                Console.WriteLine("{0}: Could not obtain role for this RID.", roleName)
            End Try
        Next roleName
        ' Get the role using the string value of the role.
        Console.WriteLine("{0}? {1}.", "Administrators", myPrincipal.IsInRole("BUILTIN\" + "Administrators"))
        Console.WriteLine("{0}? {1}.", "Users", myPrincipal.IsInRole("BUILTIN\" + "Users"))
        ' Get the role using the WindowsBuiltInRole enumeration value.
        Console.WriteLine("{0}? {1}.", WindowsBuiltInRole.Administrator, myPrincipal.IsInRole(WindowsBuiltInRole.Administrator))
        ' Get the role using the WellKnownSidType.
        Dim sid As New SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, Nothing)
        Console.WriteLine("WellKnownSidType BuiltinAdministratorsSid  {0}? {1}.", sid.Value, myPrincipal.IsInRole(sid))

    End Sub

    Public Shared Sub Main()
        DemonstrateWindowsBuiltInRoleEnum()

    End Sub
End Class

承認Authorization

承認とは、要求されたアクションの実行をプリンシパルに許可するかどうかを判断するプロセスです。Authorization is the process of determining whether a principal is allowed to perform a requested action. 承認は認証の後に行われ、プリンシパルの ID とロールについての情報を使用して、そのプリンシパルがアクセスできるリソースを判断します。Authorization occurs after authentication and uses information about the principal's identity and roles to determine what resources the principal can access. 承認は、.NET Framework のロール ベース セキュリティを使用して実装できます。You can use .NET Framework role-based security to implement authorization.