Azure-in-bullet-points

Implementing Authentication and Secure Data

• Authentication
  • Act of verifying someone’s identity.
  • Who are you?
• Authorization
  • Act of verifying if someone has access to a certain operation/subsystem.
  • What can you do?

Authentication

• Certificate-based authentication
  • Client establish its identity to a server by using a digital certificate.
  • Additional security for user authentication.
  • In Azure, its handled by AAD.
  • You can authenticate to e.g. custom services, Office 365, Skype for Business, API Management, SharePoint..
  • Good when multiple front-ends to back-ends architecture is in place.
  • Solutions
    • Traditionally: Install certificate on each server to establish trust.
    • In cloud native for hybrid scenarios:
      • Restrict access to Azure web app.
    • You can use over SSL/TLS
    • You can set API Management to use client certifications.
• Azure Active Directory ^{IDaaS: Identity as a Service}
  • Identity & access management on Azure with directory services, identity governance and application access management (access control).
  • Quickly enables SSO to commercial apps in marketplace and custom apps.
  • You communicate through Azure AD Graph API or Microsoft Graph.
  • AD DS vs Azure AD
    • Both store directory data and manage communication including logon processes, authentication and directory sources.
    • Azure AD is not domain controller in cloud, new way of thinking.
    • Active Directory Domain Services ADDS
      • Introduced with Windows 200 server.
      • Hierarchical structure based on X.500
      • DNS for locating objects, LDAP for interactions, Kerberos for authentication.
      • Create trusts between domains
        • With Organizational Units (OUs) and Group Policy Objects (GPOs) and joining machine to a domain.
    • ADDS is not the solution for cloud because
      • Perimeterless enterprises requires new solution
        • Perimeter Network (DMZ) : exposing external services to an untrusted network (e.g. internet).
      • Cloud handles security instead of corporate firewall.
    • Azure AD
      • One common identity for users (on-prem + cloud)
      • Seamless, risk-based data protection controls
        • Backed by ML and in-depth reporting
      • No OUs (organizational units) or GPOs (group policy objects).
      • SAML, WS-Federation or OAuth protocols for authentication.
      • No LDAP but REST API calls to Azure AD Graph API for interaction.
      • Works over HTTP/HTTPS.
      • Managed Service Identity
        • Managed identities is new name for Azure Active Directory Managed Service Identity (MSI)
        • A way to keep credentials outside of code.
          1. Your code calls a local MSI endpoint to get an access token (OAuth2)
          2. MSI uses the locally injected credentials to get an access token from Azure AD
          3. Your code uses this access token to authenticate to an Azure service
        • When you enable MSI for an Azure service:
          • Azure creates a Service Principal for the instance of the service in Azure AD
          • Injects the credentials (client ID and certificate) for the Service Principal into the instance of the service
        • Two types:
          • System assigned: Added & managed by azure.
            • Turn on / off: Resource -> Identity blade -> On/Off
            • Enables Azure resources to authenticate to cloud services (e.g. Azure Key Vault) without storing credentials in code.
            • RBAC permissions can be controlled in Azure AD
          • User assigned: User assignes identities
            • First create Managed Identity
              • It’s an ARM object where you can add/remove role assigments.
              • Managed Identities > +Add
            • Resource -> Identity -> User assigned -> +Add
            • You can use this identity to authenticate to services that support Azure AD authentication, without needing credentials in your code.
  • Azure AD Connect
    • Integrates on-premises directories with Azure AD.
    • Three primary components:
      • Health monitoring
      • Synchronization
        • Creates users, groups and other objects.
        • Ensures match between on-prem <=> cloud
      • Active Directory Federation Services (AD FS)
        • Configures hybrid environment with on-prem AD FS.
        • Good for organizations with complex deployments:
          • domain-joins SSO, enforce Azure AD sign-in policy, smart card + third party MFA.
    • Features
      • Filtering: Limit objects to be synced by filtering by domains, OUs or attributes.
      • Password hash syncrhronization: On-prem AD is the authority so you can use your own password policy.
      • _Password write_back: Users can reset & change their passwords in cloud and have on-prem policies applied.
      • Device writeback: Registered device in Azure AD is written in on-prem AD so it can be used for conditional access.
      • Prevent accidental deletes: Limits delete operations (default: 500 per run)
      • Automatic upgrade: Updates itself to the latest AD Connect.
  • More about AD FS
    • Part of AD DS. Uses it as an identity provider.
    • Consists of two machines that trust each other
      1. Resource Server (e.g. AD DS):
         • Authenticates & issues a token.
      2. Federation server (AD FS): identity provider
         • Validates token & issues identity token for other local servers to accept.
    • Flow: App -> Resource Server (AD DS) -> Federation Server (id provider) (AD FS)
    • Provides SSO across organizational boundaries.
    • Uses claims-based access-control and implement federated identity.
• Legacy authentication methods
  • Forms-based authentication
    • Uses HTML from to send user’s credentials to the server.
    • Disadvantages:
      • Requires user to interact with HTML web application.
      • Requires measures to prevent cross-site request forgery (CSFR)
      • User credentials are sent in plaintext as part of a request.
  • Windows-based authentication
    • Users log in with Windows credentials using Kerberos or NTLM.
    • Credentials are sent in Authorization header.
    • Best suited for intranet.
    • Disadvantages:
      • Difficult to use in internet without exposing all user dictionary.
      • Can’t be used for BYOD (bring your own device)
      • Requires Kerberos or NTLM (Integrated Windows Authentication) support in client browser or device.
      • Client must be joined to Active Directory Domain.
    • In hybrid environment, it can be used to manage physical machines and to enable simple Windows-based authentication.
• Token-based authentication
  • Claims-based authentication in .NET
    • Evolution
      • Before: Federation with SQL DB for user names, passwords, profile data.
      • Today: Hard to handle social identity providers when many of them implement storage, tokens & claims
    • Identity: a set of claims
      • More expressive than roles (booleans)
      • Returned as series of claims by most social providers
    • .NET identity implemantation
      • Unified identity solution for ASP .NET applications.
      • Implement provider model for logins
        • You can simply add, remove or replace providers (e.g. AD DS, Azure AD, Facebook, Google)
      • Supports claims-based authentication
        • Integrates with most social providers including Azure AD.
  • App Service authentication and authorization
    • It’s built-in, no code or SDK is required
      • Runs separately as easyauth.dll
    • Claims are injected to .NET and other (e.g. PHP) applications.
    • Runs in same sandbox as application code.
    • Handles HTTP requests before application.
    • Has built-in token store (token repository)
      • You can collect & store & refresh tokens.
      • E.g.:
        • Post to authenticated user’s Facebook timeline
        • Read users data from Azure AD Graph API or event from Microsoft Graph.
  • Multi-factor authentication (MFA)
    • One factor (e.g. password) is weak.
    • Recommended to have at least two of the following:
      • Knowledge
        • Something only the user knows.
        • E.g. security questions, passwords, PIN.
      • Possession
        • Something only the user has.
        • E.g. corporate badge, mobile device, security token.
      • Inherence
        • Something that user is.
        • E.g. fingerprint, face, voice, iris.
    • Implement using Azure AD
      • Two ways to enable
        • Enable for each user:
          • Two-step verification each time users sign in.
          • Exceptions: Trusted IP addresses, remembered devices is turned on.
        • Conditional access policy
          • Uses the *Azure AD Identity Protection risk policy to require two-step verification based only on the sign-in risk for all cloud applications.
      • Available verification methods:
        • Call to phone
        • Text Message to phone
        • Through Authenticator App (phone app from Microsoft):
          • Notification through mobile app
          • Verification code from mobile app
      • 💡 Consider using Trusted IPs or named locations as a way to minimize two-step verification prompts.
    • Implement using .NET
      • Multi-Factor Authentication SDK for C#, Java, Perl, PHP, Ruby.
        • Each SDK includes a certificate & private key for encryption transactions that are unique to your MFA provider.
        • ❗ Limitations:
          • APIs have no access to users in Azure AD, you provide them.
          • No enrollment & user management features.
• Implement OAuth2 ^tutorial
  • In Azure AD
    • App registrations -> Register server + client apps with URLs.
      • For client: Settings -> Keys -> Passwords -> Create key with expiration date.
    • Grant permissions to allow the client-app to call the backend-app.
      • AD -> Application registrations -> client-app -> Settings -> Required permissions -> Add -> Select API (backend-app) -> Select permission Access backend-app
  • In API Management instance
    • Configure OAuth2.0 server
      • OAuth 2.0 -> Add -> Type Token/Auth URL’s (you can find in Endpoints page in AD) -> Add body parameter named resource, type Application ID of backend-app -> Client ID: use Application ID for the client-app -> Client secret: type secret you created in client app -> Copy redirect_url -> Create -> Go to Settings page of the client-app -> Reply URLs => Paste redirect_url
    • Protect API with OAuth 2.0
      • API’s -> Select back-end app -> Settings -> Security -> Choose 2.0 -> Select OAuth2.0 server configured earlier -> Save
      • Enable JWT validation for pre-authorizing requests: edit Policy XML add JWT logic.

Authorization

• Evolution
  • Authorization in past
    • Protocols like LDAP or tools like AD DS.
    • Application queried database whenever a user attempted to access an application.
  • Today
    • Identity is managed by 3rd parties (Azure AD, Facebook, Google)
    • Information needs to be shared in a standardized way to applications.
  • Simplest solution: Once users are logged in, ID provider is trusted by application and can share claims.
• Claims-based authorization
  • To grant or deny access is based on arbitrary logic that uses data available in claims to make the decision
    • Claim
      • Name/value pair that represents what the subject is and not what the subject can do
      • E.g. DateOfBirth = June 8, 1970
  • Implementation in .NET
    • Claim-based authorization checks are declarative
      • Embedded in code against an action/controller, specifying claims required for current user, and optionally values of claims.
    • Claims requirements are defined in policies.
      • Define policies in Startup.ConfigureServices.

        • Require claim(s)

          services.AddAuthorization(options => options.AddPolicy("EmployeeOnly", policy => policy.RequireClaim("EmployeeNumber")));
          

        • Require claim values

          services.AddAuthorization(options => options.AddPolicy("Founders", policy => policy.RequireClaim("EmployeeNumber", "1", "2", "3", "4", "5")));
          

      • Apply policies on action/controller using [Authorize(Policy = "EmployeeOnly")]
        • 💡 Action overrides controller.
• Role-based access control (RBAC) authorization
  • An identity can belong to one or more roles.
  • Access is granted or denied based on roles.
  • In ASP .NET
    • Authorize per role [Authorize(Roles = "HRManager")] or [Authorize(Roles = "HRManager,Finance")]
    • 💡 Actions overrides controller declarations.
    • For only authenticating, you can use [Authorize] and [AllowAnonymous]
    • You can declare policies based on roles.
      • In Startup.ConfigureServices
        • Require single role: options.AddPolicy("RequireAdministratorRole", policy => policy.RequireRole("Administrator"))
        • Require multiple roles: options.AddPolicy("ElevatedRights", policy =>policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));
    • On actions and controllers you can then use [Authorize(Policy = "RequireAdministratorRole")]
  • ❗ RBAC is built in ARM so classic deployment cannot use it
  • Best practice: Grant users/team least privileges to get their work done.
  • Role assignment Grant access by assigning a Security Principal, a Role at a Scope
    • Security principal. User, group or service principal.
    • Role : Built-in or custom role
      • Roles are specific to level, app type (VM, storage)
    • Scope : Subscription, resource group or resource
  • Azure has 70 built-in roles. Fundamental roles that apply all resource types:
    • Owner: Root, can delegate, can be scoped.
    • Contributor: Creates & manages but cannot delegate.
    • Reader: Read only access
    • User access administrator: Manages user access to Azure resources

Encryption

• Encryption: Plaintext => Ciphertext, Decryption: Ciphertext => Plaintext
• Symmetric encryption
  • Uses symmetric key to encrypt & decrypt
    • The longer the key, the better it is
• Good encryption algorithm: been in use in several years + resisted all attacks.
• Encryption at rest
  • Encoding (encryption) of data when it is persisted (stored)
  • Azure uses symmetric encryption
    • For partitioned data, different keys may be used for each partition.
    • Data encryption keys are often encrypted with asymmetric encryption.
  • Flow: Resource providers <=> Data Encryption keys (DEKs) => Key encryption keys (KEKs) => Azure Key Vault (protected by Azure AD)
  • Azure Storage
    • Enabled by default, cannot be disabled using Storage Service Encryption (SSE)
      • Does not affect the performance
      • You can use Encryption Blade to use custom key.
    • Some services support customer managed keys & client-side encryption
  • Azure SQL Database Encryption
    • Uses TDE (Transparent Data Encryption) on server level as default.
      • Encrypts data + log files.
        • Encryption happens in page level
          • Encrypted before writing to disk
          • Decrypted when read into memory
      • Encrypts also SQL server + Azure SQL Data Warehouse.
      • Does not increase the size of the encrypted database.
      • Uses database encryption key (DEK)
        • The key is stored in database boot record with a certificate for availability during recovery.
        • It can be symmetric key in master DB server, or asymmetric key protected by EKM (Extensible Key Management)
  • Azure Cosmos DB encryption
    • Database, media attachments, backups are encrypted by default.
      • Primary database is generally stored in SSD’s
      • Media attachments & back-ups are stored in Blob storage (generally HDD’s)
• Always Encrypted
  • In Azure SQL Database and SQL server.
  • Data is never plaintext inside database.
  • Encrypted at rest, during movement between client <=> server, in another words when data is in use.
  • Clients decrypts data with a key unknown to DB.
    • Separation between who own the data and who manage the data.
  • Requires code changes, driver installed in server, change in connection string.
• Azure confidential computing
  • Designed when data will never be in plaintext in cloud.
  • Hardware vendors help it (e.g. Intel)
    • Trusted Execution Environment
      • No one can see the data.
      • If code is changed, operations are denied & environment is disabled.
      • No code changes required.
      • Exposed:
        • Hardware: Intel CPU’s with Intel SGX are available in VM’s.
        • Software: SGX SDK + 3rd party can be used in VM & compute.
        • Services: Many Azure services including Azure SQL.
        • Frameworks: Ex: Confidential Consortium Blockchain Framework by Microsoft Research Team.
• SSL & TLS
  • Security for communications over computer network.
  • Secure Sockets Layer (SSL)
    • Used by many Azure services.
    • ❗ SSL (1.0, 2.0, 3.0) are vulnerable and prohibited by IETF.
  • Transport Layer Security (TLS)
    • ❗ TLS 1.0 is insecure because of block chippers (CBC & RC2 CBC) and stream cipher (RC4).
    • 💡 Recommended: Higher than TLS 1.0.
    • Supported by Azure Storage (default: TLS 1.2)
• Azure Key Vault
  • Secrets store for e.g. password, DB credentials, API key, certificates.
    • Each secret gets URL, vault name must be unique.
  • Backed by hardware security modules (HSMs)
  • Control & logs access to anything stored in them.
  • Can handle requesting & renewing TLS certificates
  • Streamlines key management process
    • Dev, test keys and migration to production keys.
  • Permissions to keys can be granted and revoked as needed.
  • Usage
    • Accessible on Azure Portal
    • In .NET: You can use Azure SDK in C# with AzureServiceTokenProvider as authentication callback.
    • In CLI:
      • az keyvault create
      • az secret set
      • az keyvault secret show
    • Rest API:
      • Create key: POST {vaultBaseUrl}/keys/{key-name}/create?api-version=7.0
      • Delete certificate: DELETE {vaultBaseUrl}/certificates/{certificate-name}?api-version=7.0
      • Get secret: GET {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.0
      • Update secret: PATCH {vaultBaseUrl}/secrets/{secret-name}/{secret-version}?api-version=7.0

This site is open source. Improve this page.