Azure Cognitive Services security

Security should be considered a top priority when developing any and all applications. With the onset of artificial intelligence enabled applications, security is even more important. In this article various aspects of Azure Cognitive Services security are outlined, such as the use of transport layer security, authentication, securely configuring sensitive data, and Customer Lockbox for customer data access.

Transport Layer Security (TLS)

All of the Cognitive Services endpoints exposed over HTTP enforce TLS 1.2. With an enforced security protocol, consumers attempting to call a Cognitive Services endpoint should adhere to these guidelines:

  • The client Operating System (OS) needs to support TLS 1.2
  • The language (and platform) used to make the HTTP call need to specify TLS 1.2 as part of the request
    • Depending on the language and platform, specifying TLS is done either implicitly or explicitly

For .NET users, consider the Transport Layer Security best practices .

Authentication

When discussing authentication, there are several common misconceptions. Authentication and authorization are often confused for one another. Identity is also a major component in security. An identity is a collection of information about a principal . Identity providers (IdP) provide identities to authentication services. Authentication is the act of verifying a user's identity. Authorization is the specification of access rights and privileges to resources for a given identity. Several of the Cognitive Services offerings, include Azure role-based access control (Azure RBAC). Azure RBAC could be used to simplify some of the ceremony involved with manually managing principals. For more details, see Azure role-based access control for Azure resources.

For more information on authentication with subscription keys, access tokens and Azure Active Directory (AAD), see authenticate requests to Azure Cognitive Services.

Environment variables and application configuration

Environment variables are name-value pairs, stored within a specific environment. A more secure alternative to using hardcoded values for sensitive data, is to use environment variables. Hardcoded values are insecure and should be avoided.

Caution

Do not use hardcoded values for sensitive data, doing so is a major security vulnerability.

Note

While environment variables are stored in plain text, they are isolated to an environment. If an environment is compromised, so too are the variables with the environment.

Set environment variable

To set environment variables, use one the following commands - where the ENVIRONMENT_VARIABLE_KEY is the named key and value is the value stored in the environment variable.

Create and assign persisted environment variable, given the value.

:: Assigns the env var to the value
setx ENVIRONMENT_VARIABLE_KEY="value"

In a new instance of the Command Prompt, read the environment variable.

:: Prints the env var value
echo %ENVIRONMENT_VARIABLE_KEY%

Tip

After setting an environment variable, restart your integrated development environment (IDE) to ensure that newly added environment variables are available.

Get environment variable

To get an environment variable, it must be read into memory. Depending on the language you're using, consider the following code snippets. These code snippets demonstrate how to get environment variable given the ENVIRONMENT_VARIABLE_KEY and assign to a variable named value.

For more information, see Environment.GetEnvironmentVariable .

using static System.Environment;

class Program
{
    static void Main()
    {
        // Get the named env var, and assign it to the value variable
        var value =
            GetEnvironmentVariable(
                "ENVIRONMENT_VARIABLE_KEY");
    }
}

Customer Lockbox

Customer Lockbox for Microsoft Azure provides an interface for customers to review, and approve or reject customer data access requests. It is used in cases where a Microsoft engineer needs to access customer data during a support request. For information on how Customer Lockbox requests are initiated, tracked, and stored for later reviews and audits, see Customer Lockbox.

Customer Lockbox is available for this service:

  • Translator
  • Conversational language understanding
  • Custom text classification
  • Custom named entity recognition
  • Orchestration workflow

For the following services, Microsoft engineers will not access any customer data in the E0 tier:

  • Language Understanding
  • Face
  • Content Moderator
  • Personalizer

To request the ability to use the E0 SKU, fill out and submit this request Form. It will take approximately 3-5 business days to hear back on the status of your request. Depending on demand, you may be placed in a queue and approved as space becomes available. Once approved for using the E0 SKU with LUIS, you'll need to create a new resource from the Azure portal and select E0 as the Pricing Tier. Users won't be able to upgrade from the F0 to the new E0 SKU.

The Speech service doesn't currently support Customer Lockbox. However, customer data can be stored using bring your own storage (BYOS), allowing you to achieve similar data controls to Customer Lockbox. Keep in mind that Speech service data stays and is processed in the region where the Speech resource was created. This applies to any data at rest and data in transit. When using customization features, like Custom Speech and Custom Voice, all customer data is transferred, stored, and processed in the same region where your BYOS (if used) and Speech service resource reside.

Important

Microsoft does not use customer data to improve its Speech models. Additionally, if endpoint logging is disabled and no customizations are used, then no customer data is stored.

Next steps