Patent Description:
<CIT> describes a mechanism for secure data storage in a distributed computing system by a client of the distributed computing system, wherein gateway device intercepts a data file from at least a portion of stream data during transmission, and if the destination of the data file is the storage, the gateway device selects a set of analysis algorithms to determine whether the data file comprises sensitive data.

Various techniques will be described with reference to the drawings, in which:.

In various examples below, techniques for protecting against unauthorized access to data are discussed. Data entering and/or traveling along various networks operated by a computing resource service provider is encrypted and secured from unauthorized access by various intermediaries along a network path to a backend service or other resting point for the sensitive data. In addition, encrypted sensitive data exiting various networks operated by the computing resource service provider may be decrypted such that the sensitive data is accessible to a client device. This sensitive data may include credit card number, e-mail address, physical addresses, passport number, telephone numbers, contacts, passwords, banking information, customer identification information, communications, or any other information a customer may consider private and/or sensitive. The computing resource service provider may provide a variety of services and/or support (e.g., by providing access to computing resources) to other entities providing services to customers.

These services may expose (e.g., make an interface available via a public communications network) various service endpoints to the customers, and the service endpoints may be connected to a public network such as the Internet. For example, a customer may interact with a retail service exposed as a website to customers. The customer interactions may include Hypertext Transfer Protocol (HTTP) requests (e.g., GET and POST requests) transmitted towards the retail service or other backend services that support the request. Furthermore, the requests may be directed towards the backend services by various proxy devices and/or proxy fleets. As described above, sensitive data is protected using various encryption techniques such as Transport Layer Security (TLS), Secure Socket Layer (SSL), and/or Hypertext Transfer Protocol Secure (HTTPS) and others, such as described below. However, the methods involve data being decrypted by the proxy devices and/or proxy fleets, for example, so that the data can be routed to the appropriate backend service and/or that sensitive data be decrypted or other modifications be made to the encrypted data stream. Therefore, to ensure that the sensitive data is not exposed as a result, the operation of the proxy devices and/or proxy fleets may be modified to improve security and efficiency as described in greater detail below.

A data protection module may be executed by the proxy devices and/or proxy fleets to provide protection of sensitive data as described in the present disclosure. The data protection module may be executed in an isolated environment or otherwise protected from access from outside of the data protection module. Configuration information may be generated based at least in part on the backend service and provided to the data protection modules executed by the proxy devices and/or proxy fleets. The configuration information may include a variety of information described in greater detail below such as cryptographic material, various definitions of sensitive data, policy information, or other information suitable for protecting sensitive data. Each data protection module may service a single backend service or a plurality of backend services. In addition, the data protection module may enforce various cryptographic algorithms described in greater detail below such as Public Key Cryptography Standards (PKCS).

The data protection module may perform different operations for data entering or exiting the computing resource service provider environment. For example, sensitive data directed towards a client device from a backend service may first be rendered or otherwise formatted for display by the client device prior to decrypting sensitive data directed towards the client device. In various embodiments, the sensitive data may include a signature or other information to be validated before the data protection module decrypts the sensitive data. As above, sensitive data may be secured outside of the computing resource service provider environment using a secure link such as TLS. Other mechanisms for protecting sensitive data are considered within the scope of the present disclosure, for example, the sensitive data may be encrypted with a public key associated with a customer prior to transmission of the sensitive data to a client device associated with the customer.

In various examples, the proxy devices and/or proxy fleets may be a part of or integrated in various content delivery networks (CDNs). These CDNs enable lower latency communication with the customers and provide efficient processing for customer requests. As described above, the data protection module may be implemented by the proxy devices and/or proxy fleets included in the CDN. In addition, the computing resource service provider or other entity may operate a key management system, described in greater detail below, to provide efficient access to cryptographic material and/or cryptographic functions. For example, when receiving sensitive data to encrypt or decrypt, the data protection module may request executing of the operation by the key management service. The key management service may be a process of the proxy devices and/or proxy fleets or may be executed on a separate computing device accessible to the data protection module.

In the preceding and following description, various techniques are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of possible ways of implementing the techniques. However, it will also be apparent that the techniques described below may be practiced in different configurations without the specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the techniques being described.

<FIG> illustrates an environment <NUM> in which a secure proxy fleet <NUM> may protect sensitive data from exposure to intermediaries with a computing resource service provider environment in accordance with an embodiment. A computing resource service provider <NUM> may provide customers <NUM> with access to various backend services <NUM>. The backend services <NUM> may be operated by the computing resource service provider <NUM> or other entities. For example, the computing resource service provider <NUM> may provide an organization with access to computing resources provided by the computing resource service provide <NUM> to implement various services exposed to customers <NUM>, such as a streaming media service, website, or other application. The computing resource service provider <NUM> may operate various networks, computing devices, services, applications, or other computing resources and provide customers <NUM> and other entities access to perform various operations.

As illustrated in <FIG>, the customers <NUM> may send and receive sensitive data to one or more backend services <NUM> hosted by the computing resource service provider <NUM>. Furthermore, the sensitive data may be exposed to one or more intermediaries <NUM> along a network path to the one or more backend services <NUM>. In various embodiments, the intermediaries <NUM> may not be authorized to access the sensitive data. In addition, the intermediaries <NUM> may include any computing resource operated by the computing resource service provider <NUM> or other entity. For example, a particular intermediary may include a network congestion service of the computing resource service provider <NUM> with access to packets traveling over a network.

Customers <NUM> or other entities associated with sensitive data may want to read and/or write access to sensitive data restricted to trusted entities, both computing devices and persons. As described above, the computing resource service provider <NUM> may define and determine various requirements to maintain the security and privacy of sensitive information by regulation, legal privilege, competitiveness, contractually (e.g., pricing or other terms with vendors), or any other need to protect sensitive data. Sensitive data includes an address, passport number, a tax identifier, legal information, financial information, customer lists and/or specific customer identifying information, mergers-and-acquisition, employee health records and personnel files, and customer payment instruments. Furthermore, sensitive data may include any data that may be categorized as sensitive or otherwise categorized as data to be protected. To protect sensitive data, the computing resource service provider <NUM> may operate a secure proxy fleet <NUM>. The secure proxy fleet <NUM> may encrypt sensitive data as it comes in to the computing resource service provider environment (e.g., data centers, networks, and other computing resources operated by the computing resource service provider <NUM>) and direct encrypted sensitive data to a single point of trust (e.g., protected resources of the one or more backend services <NUM>) inside the computing resource service provider environment.

The sensitive data is encrypted so that access to the sensitive data may be controlled by controlling access to cryptographic material used to encrypt the sensitive data. For example, access to the sensitive data may be provided by a key management service, described in greater detail below, distributing an encryption key used to encrypt the sensitive data. The encryption may be performed using various encryption standards as described in the present disclosure such as PKCS. In addition, other safeguards may be used to secure the sensitive data. For example, a security policy or other mechanism is used to ensure that sensitive data is not stored in memory for longer than <NUM> seconds before the request is failed and must be retried. The secure proxy fleet <NUM> may be implemented using physical computing resources of the computing resource service provider <NUM> including networking devices and server computer systems.

The secure proxy fleet <NUM> may include applications or other executable code executed by the physical computing resources. As described in greater detail below, the secure proxy fleet <NUM> may manage and maintain cryptographic material to encrypt the sensitive data. In addition, the secure proxy fleet <NUM> proxy or otherwise forwards requests between the one or more backend services <NUM> and customers <NUM>. For example, a particular service may expose an endpoint on a public network such as the Internet. The endpoint may allow customers <NUM> to communicate with the particular backend service by directing service requests to the endpoint exposed on the public network. The secure proxy fleet <NUM> may obtain service requests directed to the endpoint and forward the requests to the particular backend service based at least in part on information included in the service requests. For the purposes of the present disclosure, a request, service call, or other data may be directed towards a destination address (e.g., IP address, email address, SMS number, etc) associated with the entity that the request, service call, or other data is "directed towards.

Furthermore, the secure proxy fleet <NUM> may operate a single proxy for each backend service and/or endpoint exposed to the customer <NUM>. For example, a particular backend service exposes different endpoints for various types of sensitive data, such as a first endpoint for customer identifying information and a second endpoint for customer payment information. The secure proxy fleet <NUM> may isolate the processing of requests directed to each endpoint, for example, by physical isolation (e.g., processing separated by different physical computing hardware) or logical isolation (e.g., process isolation using sandboxing).

The backend services <NUM>, as described above, may be provided by the computing resource service provider <NUM> or may be provided by one or more other entities utilizing computing resources of the computing resource service provider <NUM>. The backend services <NUM> may include a number of services such as a retail service, computing instance service, on-demand storage service, block-level storage service, networking service, notification service, document management service, messaging service, or any other service implemented using computing resources of the computing resource service provider <NUM>. For example, the backend services <NUM> may access the data stores illustrated in <FIG> and <FIG> though an internal web service.

The intermediaries <NUM> may include any number of computing resources and/or services of the computing resource service provider <NUM>. In addition, the intermediaries may be operated by other entities besides the computing resource service provider <NUM>. For example, a particular intermediary may include data storage service utilizing various networks of the computing resource service provider <NUM> to send and receive data from customers <NUM>. The intermediaries <NUM> may also enforce various security policies and/or levels of security.

<FIG> illustrates an environment <NUM> in which a secure proxy fleet <NUM> and a proxy fleet may send and receive protected sensitive data to backend services <NUM> in accordance with an embodiment. A computing resource service provider <NUM> may provide customers with access to the backend services <NUM>. The customers may access the backend services <NUM> through a webpage <NUM> or other application that communicates data to the backend services over a network, such as a stand-alone application or mobile application. The backend services <NUM> may be operated by the computing resource service provider <NUM> or other entities. For example, the computing resource service provider <NUM> may provide an organization with access to computing resources provided by the computing resource service provider <NUM> to implement various services exposed to customers, such as a streaming media service, website, or other application. The computing resource service provider <NUM> may operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations.

As illustrated in <FIG>, customers may send and receive sensitive data and non-sensitive data to one or more backend services <NUM> hosted by the computing resource service provider <NUM>. Furthermore, the sensitive data and non-sensitive data may be exposed to one or more intermediaries <NUM> along a network path to the backend services <NUM>. In various embodiments, the intermediaries <NUM> may not be authorized to access the sensitive data. In addition, the intermediaries <NUM> may include any computing resource operated by the computing resource service provider <NUM> or other entity. For example, a particular intermediary may include network congestion service of the computing resource service provider <NUM> with access to packets traveling over a network.

Returning to <FIG>, a customer's computing device may transmit one or more HTTP requests to online proxy fleet <NUM> or secure proxy fleet <NUM> of the computing resource service provider <NUM>. The online proxy fleet <NUM> and the secure proxy fleet <NUM> may be a collection (e.g., logical or physical grouping) of computing resources including executable instructions that, as a result of being executed by one or more processors of the computing resources, cause the computing resources to receive HTTP requests and direct those HTTP requests to one or more backend services <NUM> of the computing resource service provider <NUM>. The online proxy fleet <NUM> and the secure proxy fleet <NUM> may be responsible for directing requests to the appropriate backend service <NUM> of the computing resource service provider <NUM> for processing.

The online proxy fleet <NUM> and the secure proxy fleet <NUM> may stream and/or transmit customer's request obtained as a result of the customer interaction with the webpage <NUM>. The online proxy fleet <NUM> and the secure proxy fleet <NUM> may be executed within the same computing resource or same process executed within the computing resource. In this manner, requests including sensitive data or non-sensitive data can be processed appropriately. For example, requests including sensitive data may be transmitted to the same proxy device (e.g., a computing device executing both the online proxy fleet <NUM> and the secure proxy fleet <NUM>) as requests including other data. The traffic may be differentiated at the proxy device based at least in part on an endpoint the request is directed to. For example, the webpage <NUM> may be configured such that HTTP request including sensitive data are directed an endpoint monitored by a secure proxy fleet <NUM>. In addition, the webpage <NUM> may directed HTTP request including non-sensitive data to endpoints monitored by the online proxy fleet <NUM>.

<FIG> illustrates an environment <NUM> in which a secure proxy fleet <NUM> receives and protects sensitive data prior to forwarding the sensitive data to backend services <NUM> in accordance with an embodiment. A computing resource service provider <NUM> may provide customers <NUM> with access to the backend services <NUM>. The customers <NUM> may access the backend services <NUM> through a webpage, service call, user interface, or application, such as a stand-alone application or mobile application that communicates data to the backend services <NUM> over a network. The backend services <NUM> may be operated by the computing resource service provider <NUM> or other entities. For example, the computing resource service provider <NUM> may provide an organization with access to computing resources provided by the computing resource service provider <NUM> to implement various services exposed to customer <NUM>, such as a streaming media service, website, or other application. The computing resource service provider <NUM> may operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations.

As illustrated in <FIG>, the customers <NUM> may send sensitive data to one or more backend services <NUM> hosted by the computing resource service provider <NUM>. The sensitive data may be directed to a trusted entity or location operated by the backend services <NUM>. Furthermore, the sensitive data may be encrypted by a data protection module <NUM> of the secure proxy fleet <NUM> to prevent exposure of the sensitive data to one or more intermediaries <NUM> along a network path to the one or more backend services <NUM>. In various embodiments, the intermediaries <NUM> may not be authorized to access the sensitive data. In addition, the intermediaries <NUM> may include any computing resource operated by the computing resource service provider <NUM> or other entity. For example, a particular intermediary may include stream service of the computing resource service provider <NUM> with access to computing resources of the computing resource service provider environment.

The intermediaries <NUM> may include any number of computing resources and/or services of the computing resource service provider <NUM>. In addition, the intermediaries <NUM> may be operated by other entities besides the computing resource service provider <NUM>. For example, a particular intermediary may include data storage service utilizing various networks of the computing resource service provider <NUM> to send and receive data from customers <NUM>. The intermediaries <NUM> may also enforce various security policies and/or levels of security.

As described in greater detail below, the data protection module <NUM> may detect sensitive data obtained from a request or data stream directed towards the backend services. In addition, the secure proxy fleet <NUM> and/or data protection module <NUM> may be a terminator for a TLS or other secure connection. In other words, the secure proxy fleet <NUM> and/or data protection module <NUM> may be responsible for establishing and maintaining one end of a secure link between the customer <NUM> and the backend service <NUM>. In some examples, the secure proxy fleet <NUM> establishes an encrypted network connection by using a TLS connection. In other examples, the encrypted network connection is established by negotiating a symmetric key using a key exchange algorithm.

The data protection module <NUM> may be processes or applications executed by the same computer system executing the secure proxy fleet <NUM>. In yet other embodiments, the secure provider fleet <NUM> may be executed by dedicated hardware which also executes the data protection module <NUM> as a component of the secure proxy fleet <NUM>. As describe in greater detail below, the data protection module <NUM> may be implemented using configuration information generated by the backend service <NUM>, computing resource service provider <NUM>, or other entity. The configuration information may indicate to the data protection module <NUM> data that is sensitive, how to detect sensitive data, how to process and/or protect data that is sensitive, how to encrypt sensitive data, encryption algorithms to encrypt sensitive data, encryption keys, endpoints to transmit encrypted data to, or any other information suitable for protecting the sensitive data.

As illustrated in <FIG>, sensitive data may be encrypted and transmitted over one or more intermediaries <NUM> to the backend services <NUM>. The backend services <NUM> may obtain or may already contain cryptographic material required to decrypt the sensitive data. In other embodiments described below, the backend services <NUM> may request the cryptographic material or decryption of the cryptographic material for a key management service. In addition, the secure proxy fleet <NUM> may transmit data that is not sensitive to the backend service <NUM> in plaintext. For example, the customer may send an HTTP POST request to a particular backend service including the customers telephone number, the secure proxy feel <NUM> may encrypt the telephone number included in the HTTP POST request, such that the telephone number is undecipherable without the encryption key, but leave the remainder of the HTTP POST request in plaintext such that the request may be routed to the appropriate backend service and may be at least partially processed without requiring the entire request to be decrypted.

<FIG> illustrates an environment <NUM> in which a secure proxy fleet <NUM> receives and protects sensitive data using a cryptographic key service <NUM> prior to forwarding the sensitive data to backend services <NUM> in accordance with an embodiment. A computing resource service provider <NUM> may provide customers <NUM> with access to the backend services <NUM>. The customers <NUM> may access the backend services <NUM> through a webpage, service call, user interface, command line interface, or application, such as a stand-alone application or mobile application that communicates data to the backend services <NUM> over one or more networks <NUM>. The backend services <NUM> may be operated by the computing resource service provider <NUM> or other entities. For example, the computing resource service provider <NUM> may provide an organization with access to computing resources provided by the computing resource service provider <NUM> to implement various services exposed to customer <NUM>, such as an online retail service, website, or other application. The computing resource service provider <NUM> may operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations.

As illustrated in <FIG>, the customers <NUM> may send and receive sensitive data protected through the use of a cryptographic key service <NUM> hosted by the computing resource service provider <NUM> or other entity. The sensitive data may be directed to a trusted entity or location operated by the backend services <NUM>. Furthermore, the sensitive data may be encrypted by an encryption module <NUM> of the secure proxy fleet <NUM> to prevent exposure of the sensitive data along a network path of the one or more networks <NUM> to the one or more backend services <NUM>. In various embodiments, the encryption module <NUM> may transmit an API call to the cryptographic key service <NUM> to encrypt sensitive data. In one example, the encryption module <NUM> may request key material from the cryptographic key service <NUM> which is used to encrypt the sensitive data.

In addition, the key material may be encrypted by the cryptographic key service <NUM>. In other words, the data transmitted to the cryptographic key service <NUM> may be reduced by simply obtaining and encrypting cryptographic keys from the cryptographic key service <NUM>. In another example, the encryption module <NUM> may transmit the sensitive data in the encryption request to the cryptographic key service <NUM>, in response the cryptographic key service <NUM> returns encrypted sensitive data and, in some embodiments, the encryption key (encrypted or in plaintext) returns it to the encryption module <NUM>.

Although the cryptographic key service <NUM> depicted in <FIG> is illustrated as a separate entity, all or a portion of the functionality of the cryptographic key service <NUM> may be included in the secure proxy fleet <NUM> and/or the backend services <NUM>. For example, a portion of the cryptographic key service <NUM> may be executed as a kernel level process or micro-service by the secure proxy fleet <NUM>. In these cases, the encryption module <NUM> may transmit a request to the kernel level process of the cryptographic key service <NUM> executed by the secure proxy fleet <NUM> to obtain cryptographic material. In addition, the cryptographic key service <NUM> may periodically or aperiodically transmit and/or update the cryptographic key material maintained by the kernel level process of the cryptographic key service <NUM> executed by the secure proxy fleet <NUM>.

Returning to <FIG>, although the one or more network <NUM> are illustrated within the computing resource service provider environment, the one or more network <NUM> may include a variety of different networks implemented by various entities. For example, the one or more networks <NUM> may include a network backbone or other network structure that is part of a publicly addressable network such as the Internet. As described in greater detail below, the networks <NUM> may include public network, private network, content delivery networks, and other networks which may be implemented by different entities and/or services and may enforce different security policies and may be accessible by different entities and/or services. In addition, various computing devices may receive requests and/or data objects including sensitive data as they are routed between the customer <NUM> and the backend services <NUM>. For example, a request processing device may receive a request from the secure proxy feel <NUM>, including encrypted sensitive data directed to a particular backend service, and route the request to the appropriate instance of the backend service.

A detection module <NUM> may enable the secure proxy fleet <NUM> to detect sensitive data. Both the detection module <NUM> and the encryption module <NUM> may be a single process or plurality of processes, applications, or executable code that, when executed by one or more processors of the secure proxy fleet <NUM>, causes the secure proxy fleet <NUM> to perform the operations described in the present disclosure. In addition, both the detection module <NUM> and the encryption module <NUM> may have configuration information pushed or otherwise provided. The configuration information may include template information generated by the backend service <NUM> or administrator or other entity associated with the backend services <NUM>. The configuration information may be provided to the detection module <NUM> and the encryption module <NUM> at provisioning or instantiation of the processes executing the detection module <NUM> and the encryption module <NUM>. Furthermore, the configuration information may include information suitable for identifying sensitive data and each backend service, website, application, and/or customer may provide their own configuration information. The configuration information may indicate a data type, field, format, or flag associated with sensitive data which may be used by the detection module <NUM> to detect sensitive data.

Although not illustrated in <FIG>, a TLS terminator may convert encrypted data transmitted over a cryptographically secure communication channel (e.g., HTTPS connection) to plaintext and forward or otherwise provide decrypted data to the detection module <NUM>. In various embodiments, the detection module <NUM> parses received data (e.g., plaintext) and if the detection module <NUM> determines the received data includes sensitive data the detection module <NUM> may forward or otherwise provide the encryption module <NUM> the data to be encrypted. For example, the detection module <NUM> may receive an HTTP request from the TLS terminator and parse the HTTP request to determine that HTTP request includes a customer identification information field and provide a copy of the data in the customer identification information field to the encryption module.

The data encryption module <NUM> may return the encrypted sensitive data. The encrypted sensitive data may be returned as a data object or other format described in greater detail below. In various embodiments, the data detection module <NUM> may receive the encrypted sensitive data then replace the sensitive data with the encrypted sensitive data. Another service or process of the secure proxy fleet <NUM> may format or otherwise process the data received from the TLS termination prior to forwarding or otherwise provide the data, including the encrypted sensitive data, to the backend services. For example, the secure proxy fleet may modify length information included in the request as a result of replacing the plaintext sensitive data with the encrypted sensitive data.

The backend service <NUM> may also encrypt and protect sensitive data directed towards a client device. In such embodiments, the backend service <NUM> may generate a library call or API call to the cryptographic key management service <NUM>. The request to encrypt sensitive data to be transmitted to the client device may be the same as described above. The cryptographic key management service <NUM>, which may be a service of the computing resource service provider <NUM>, manages transparent distribution of cryptographic keys (e.g., private keys) to hosts computer systems. The backend service <NUM> may simply transmit an API call or other call to the cryptographic service to encrypt sensitive data and the cryptographic key management service <NUM> may execute one or more encryption workflows and return encrypted sensitive data.

In one example, the backend service <NUM> may transmit a customer passport number to the cryptographic management service <NUM>, which may be a remote or a local service (e.g., a daemon running a host computer system of the backend service <NUM>), then the cryptographic management service <NUM> returns the encrypted passport number to the backend service <NUM>. The encrypted data returned by the cryptographic key management service <NUM> may include other information such as a time stamp or signature. The backend service <NUM> may then generate a response, request and/or content, including the encrypted sensitive data <NUM>, to be transmitted to an endpoint such as a client device operated by the customer <NUM>.

The encrypted sensitive data may be routed across the one or more networks <NUM> towards the secure proxy service <NUM> or other service or computer system for processing. For example, the backend service <NUM> may transmit a webpage to the customer <NUM>, a rendering fleet may receive data including the encrypted sensitive data from the backend service <NUM> and convert the data into Hyper Text Markup Language (HTML) or other format. In addition, the secure proxy fleet <NUM> may perform additional processing of the data prior to or along with decrypting and inserting the sensitive data. As described above, the secure proxy fleet <NUM> may determine that the webpage directed to the customer include sensitive data based at least in part on the presence of a flag or other marker included in the data transmitted and/or intercepted by the secure proxy fleet <NUM>. The secure proxy fleet <NUM> may perform various processing operations such as unwrapping and modifying request/responses.

The cryptographic key management service <NUM> may maintain metadata associated with cryptographic keys and may determine access rights to the cryptographic key based at least in part on a security policy and/or the metadata. In addition, particular cryptographic materials may be associated with particular data types. The cryptographic key management service <NUM> may also maintain a local or centralized encryption key store. The key store may include asymmetric keys or symmetric keys. Furthermore, the cryptographic key management service <NUM> may be used to provide digital envelope encryption. In addition, various methodologies for secure out-of-band transmission of the private key (for the asymmetric case) or the symmetric key (for the digital envelope encryption case) may be maintained by the cryptographic key management service <NUM> and be subject to both periodic and aperiodic audit.

<FIG> illustrates an environment <NUM> in which a secure proxy fleet <NUM> receives sensitive data from one or more backend service <NUM> prior to forwarding the sensitive data to a customer <NUM> in accordance with an embodiment. A computing resource service provider <NUM> may provide a secure proxy fleet <NUM> to enable the backend services <NUM> to communicate with the customers <NUM>. The backend services <NUM> may communicate with the customers <NUM> through a webpage, website, service call, user interface, command line interface, or application, such as a stand-alone application or mobile application that communicates data from the backend services <NUM> over one or more intermediaries <NUM> to the customer <NUM>. The backend services <NUM> may be operated by the computing resource service provider <NUM> or other entities. For example, the computing resource service provider <NUM> may provide an organization with access to computing resources provided by the computing resource service provide <NUM> to implement various services exposed to customer <NUM>, such as an online retail service, website, or other application. The computing resource service provider <NUM> may operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations.

As illustrated in <FIG>, the backend service <NUM> may direct data including sensitive data to customer <NUM>. The sensitive data may be encrypted by the backend service <NUM> as described above. Furthermore, the encrypted sensitive data may be intercepted by the secure proxy fleet and processed or otherwise decrypted such that the sensitive data may be accessible to the customer <NUM>. The secure proxy fleet <NUM> may include a rendering module <NUM> and a decryption module <NUM>. The rendering module <NUM> and the decryption module <NUM> may be applications or processes executed by one or more processors of the secure proxy fleet <NUM>. Furthermore, the various modules and computing resources described in the present disclosure may include physical or virtual computing resources or a combination thereof. For example, the secure proxy fleet <NUM> may be executed by a virtual computer system instance supported by a physical host computer system.

Returning to <FIG>, the rending module <NUM> may render data including sensitive data directed to a client device of the customer <NUM>. For example, the data to be rendered may include a webpage containing sensitive information. The rendering module may render the webpage including encrypted sensitive information and may provide the rendered webpage to the decryption module <NUM> for decryption of the encrypted content. In yet other embodiments, the rendering module <NUM> may detect encrypted sensitive data in the rendered webpage and provide the encrypted sensitive data to the decryption module <NUM>. The decryption module may return the plaintext of the sensitive data which may be inserted into the rendered webpage by the rendering module <NUM>. In some embodiments, all or a portion of the webpage may be rendered prior to reaching the secure proxy fleet. For example, the one or more intermediaries <NUM> may include a rendering fleet which receives webpage data from the backend services <NUM> and generates rendered webpage content which may be forward to the secure proxy fleet. In addition, the intermediaries <NUM> may inject content into the data transmitted to the secure proxy fleet <NUM>.

Although a customer <NUM> is illustrated in <FIG> as the endpoint for sensitive data from the backend service <NUM>, the sensitive data may be distributed by the secure proxy fleet <NUM> to another service, for example, in a service-to-service call. In addition, the customer <NUM> may include various different computing devices or systems. For example, the customer <NUM> may include a secure storage location included in a data center operated by the customer <NUM>. As described above the secure proxy fleet <NUM>, rendering module <NUM>, and the decryption module <NUM> may receive configuration information which may define the operation of the various components. For example, the configuration information may indicate a mechanism for enabling the rendering module to detect encrypted data. In another example, the configuration information may indicate a cryptographic algorithm or key for use by the decryption module to decrypt encrypted sensitive data.

The backend service <NUM> may also maintain authorized data storage described in greater detail below in connection with <FIG>. These authorized data storage may be within the backend services <NUM> or may be in a remote location relative to the backend service <NUM> and may include a single data store or a distributed data store. The backend service <NUM> may maintain cryptographic keys and or credential information to access the authorized data storage. The backend services <NUM> may be executed using various computing devices (e.g., bare metal hypervisor, virtual machine, or a virtualization container).

The intermediaries <NUM> may include any number of untrusted intermediate computer systems or services that are either untrusted for the level of sensitivity of the data or have no authorized access to the sensitive information. Furthermore, the intermediaries <NUM> may be responsible for directing requests from the backend services <NUM> to the secure proxy fleet <NUM>. For example, data transmitted by the backend service <NUM> may be authenticated and authorized by an intermediary and then forwarded to the secure proxy fleet <NUM>. The secure proxy fleet <NUM> may determine if encrypted sensitive data is to be consumed at the destination. For example, the client device is authorized to receive the sensitive data then the secure proxy fleet may determine that the destination is able to consume the sensitive data. If the data is to be consumed by the destination (e.g., service or customer device), the sensitive data is decrypted. For example, the sensitive data may be decrypted with a private key which may be stored locally by the secure proxy fleet <NUM> in a secure storage location or remotely, for example, by a cryptographic key management service as described above. In various embodiments, the secure proxy fleet <NUM> maintains the decrypted sensitive data in memory for a short interval of time such as <NUM>-<NUM> seconds.

The backend services <NUM> may generate service calls to the secure proxy fleet <NUM> including service call to proxy website pages, including pagelets, widgets, and/or servlets. Each backend service may be considered a tenant of the secure proxy fleet, and have may a tenant identifier. Each tenant may have a reserved and isolated container in the secure proxy fleet <NUM> which may be isolated from other tenants and any other process executed by the secure proxy fleet <NUM> (e.g., an operating system). As described in greater detail below, a run-time with process isolation and mandatory access controls included in the operating system enforce this such process isolation. As a result, any chances to the operation of the secure proxy fleet <NUM> or component therefore may request termination of the process and reprovisioning of the process with new configuration information.

Each tenant container (e.g., each isolated process associated with a tenant) may be defined by configuration information including a private key or a digital envelope symmetric key for decryption, a presentation format, address information for an exposed endpoint (e.g., publicly addressable address), or other information suitable for distributing secured sensitive data. When providing sensitive data to remote devices and systems, the secure proxy fleet <NUM> may establish a cryptographically protected communications channel. In some embodiments, the secure proxy fleet <NUM> may re-establish or re-use a TLs connection generated in response to the customer <NUM> submitting a request to the backend services <NUM>. Other mechanisms may be used to secure the sensitive data once it has been decrypted by the decryption module <NUM> and is to be transmitted to the customer. For example, the data to be transmitted to the customer, including the decrypted sensitive data, may be encrypted with the customer's public key.

<FIG> is a diagram <NUM> illustrating a data stream <NUM> in accordance with an embodiment. The data stream <NUM> may be received at a secure proxy fleet as described above. The data stream <NUM> may be obtained from a customer client device or a backend service as described above. The data stream <NUM> may be compressed using a variety of compression algorithms. In addition, the data stream may include an encrypted payload <NUM>. The encrypted sensitive data <NUM> and the data stream <NUM> may be formatted by a source according to a various different formatting rules. The formatting rules may be established by the computing resource service provider and may enable efficient processing of the data stream <NUM> and information included in the data stream <NUM>.

For example, the backend service generates an HTTP response directed to a customer and formats the HTTP response to generate a compressed data stream and transmits the compressed data stream to the customer. As described above, the response may include encrypted sensitive data which may be encrypted in accordance with a particular format to enable the secure proxy fleet to process the request and decrypt the encrypted sensitive data. The encrypted payload <NUM> may have an arbitrary length and may not be known or otherwise determined prior to transmission of the encrypted payload <NUM> in the data stream <NUM>.

A flag or marker <NUM> may be included in the data stream to indicate the presence of the encrypted payload <NUM>. For example, in an embodiment a flag or marker <NUM> prior to the encrypted payload <NUM> indicates that data following the flag or marker <NUM> is sensitive data comprises the encrypted payload <NUM>. A flag or marker <NUM> following the encrypted payload <NUM> may indicate the end of the encrypted payload <NUM>. In an alternate embodiment, a flag or marker <NUM> prior to the encrypted payload <NUM> includes a data length of the encrypted payload <NUM>; in this manner, the end of the encrypted payload <NUM> can be determined without recourse to another flag or marker <NUM> following the encrypted payload <NUM>.

Other information included in the encrypted payload <NUM> either according to a particular formatting or based at least in part on an operation of the backend services include a service type, a website type, a timestamp, a signature, key material, routing information, an access policy, authentication information, authorization information, or any other information suitable for inclusion in the encrypted payload <NUM>. The format of the encrypted payload may be set by the one or more backend services, the computing resource service provider, a website operator, a customer, a public standard setting committee, or any other entity.

The payload <NUM> and/or data stream <NUM> may include metadata that is undecipherable to a computing resource without authorization. In certain embodiments, the payload <NUM> may be undecipherable but for the metadata which may indicate a variety of information include information associated with the key material used to encrypt the payload <NUM>, an entity responsible for encrypting the payload, audit information, authentication information, or other such information.

<FIG> illustrates an environment <NUM> in which a secure proxy fleet <NUM> receives sensitive from one or more exposed endpoint <NUM> and encrypts the sensitive data prior to transmitting the sensitive data to one or more authorized data stores <NUM> of one or more backend services <NUM> in accordance with an embodiment. A computing resource service provider, as described above, may provide a secure proxy fleet <NUM> to enable the backend services <NUM> to communicate with the customers through the exposed endpoints <NUM>. The exposed endpoints <NUM> may include publicly addressable resources of a network that enables communication through a webpage, website, service call, user interface, command line interface, or application, such as a stand-alone application or mobile application. For example, the exposed endpoint <NUM> may include the address "secure.

The backend services <NUM> and the authorized data stores <NUM> may be operated by the computing resource service provider <NUM> or other entities. For example, the computing resource service provider <NUM> may provide an organization with access to computing resources provided by the computing resource service provider <NUM> to implement various services exposed to customers, such as a secure storage service. The computing resource service provider <NUM> may also operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations. The authorized data stores <NUM> may include a variety of storage resources and may be implemented by one or more services such as an on-demand storage service or block-level storage service. Furthermore, authorized data stores <NUM> may provide a secure storage location to persist the sensitive data.

As illustrated in <FIG>, the secure proxy fleet <NUM> may implement an operation system <NUM>. In addition, the operating system <NUM> may provide a plurality of isolated execution environments <NUM>. The operating system <NUM> may by an operating system that support isolation and/or secure execution such as secure execution Linux (RTM). For example, the operating system <NUM> includes a kernel-level application that controls processes and prevents communications and operations of unauthorized processes. These operating systems may prevent access to processes executed in the isolated execution environment <NUM>. The secure proxy fleet may execute a TLS terminator so that HTTPS request transmitted to the exposed endpoints <NUM> are obtained and decrypted.

Furthermore, the secure proxy fleet <NUM> or other process executed by the operating system <NUM> may transmit request to the isolated execution environment <NUM> using a proxy <NUM>. The operating system <NUM> may provide the proxy <NUM> so that processes may communicate with the isolated execution environment <NUM> in a protected manner. For example, the proxy <NUM> may include a UNIX (RTM) domain socket which transmits data from process executed by the operating system <NUM> such as the TLS terminator in to the isolated execution environment <NUM>. In various embodiment, the detection module, encryption module, rendering module, decryption module, or other processes described in the present disclosure are executed within the isolated execution environments <NUM> of the operating system <NUM>.

Returning to <FIG>, the backend services <NUM> may validate that request and/or calls may to the backend services <NUM> are mutually authenticated and are authorized. Each computer system calling the backend services <NUM> may be identified itself by name, address, type, and/or the requested payload format. When receiving sensitive data the secure proxy fleet <NUM> obtain from cache or persistent storage an encryption key for the backend services <NUM> and construct a payload according to a payload format. This format information may be included in the configuration information used to provision the process in the isolated execution environment. Furthermore, the configuration and/or format information may include information indicating to a header format for a destination system and other information on how to process sensitive data to be transmitted to the backend services <NUM>. The request obtained through the exposed endpoints <NUM> may address the backend services <NUM> directly or through an API. If properly authenticated and authorized, the backend services <NUM> may return the data either to the requesting system in the case of a website or other service, or to a client computing service if so identified and authorized.

<FIG> illustrates an environment <NUM> in which a secure proxy <NUM> integrated with a content delivery network <NUM> receives sensitive data from a customer <NUM> and encrypts the sensitive data prior to transmitting the sensitive data to one or more back end services <NUM> in accordance with an embodiment. The content delivery network <NUM> may provide a secure proxy <NUM> to enable the backend services <NUM>, implemented by a computing resource service provider as described above, to communicate with the customers <NUM>. The backend services <NUM> may be operated by the computing resource service provider or other entities. For example, the computing resource service provider may provide an organization with access to computing resources provided by the computing resource service provide to implement various services exposed to customers, such as a secure streaming media service. The computing resource service provider may also operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations.

As illustrated in <FIG>, the one or more networks <NUM> may include a variety of different networks implemented by various entities. For example, the one or more networks <NUM> may include a network backbone or other network structure that is part of a publicly addressable network such as the Internet. As described in greater detail below, the networks <NUM> may include public network, private network, content delivery networks, and other networks which may be implemented by different entities and/or services and may enforce different security policies and may be accessible by different entities and/or services.

The content delivery network <NUM> may be used to cache and serve high velocity content to customers <NUM> from a network location closer in geographic proximity and/or network proximity (e.g., number of network hops) to the customers <NUM>. The customer <NUM> may request content from backend services <NUM>, which may be executed within a data center, which may maintain all of the available content. The content device network <NUM> on the other hand may store or cache a portion of the available content closer to the customer <NUM> to reduce latency. Latency may be measured in Round Trip Time (RTT), therefore requests with increased frequently it may reduce network cost and provide a better customer <NUM> experience to provide the content closer to the customer.

The content delivery network <NUM> may establish and terminate sessions using a connection terminator <NUM>. The connections may be established from the customer <NUM> to a network edge device (e.g., Point-of-Presence (POP) device). In various embodiments, the content and/or request transmitted between the network edge device and the customer <NUM> may be transmitted over a cryptographically protected communications channel such as TLS or SSL. The network edge device and the customer <NUM> may be mutually authenticated. Furthermore, the connection cryptographically protected communications channel such as a TLS connection may be a long lived session.

The content delivery network <NUM> may be operated by an entity that is distinct from the customer <NUM> and the computing resource service provider. The connection terminator <NUM> may obtain requests from the customer <NUM> and decrypt the request as described above. This may expose a plain text representation of the request which may include sensitive data. The connection terminator <NUM> and the secure proxy <NUM> may be executed in an operating system that supports isolated execution environments as described above. Furthermore, the secure proxy <NUM> may include a data protection module as described above. In various embodiments, the connection termination <NUM> decrypts the request from the customer and provides the request to the secure proxy <NUM>.

As described above, the data protection module may detect sensitive data encrypt the sensitive data prior to transmitting the request to the backend services <NUM>. Furthermore, the computing resource service provider or service thereof such as the cryptographic key service may provide key material to the secure proxy <NUM>. The key material may be used to encrypt and decrypt sensitive data as described above. In addition, the key material may be sent separate from the secure proxy <NUM> obtaining a request from the connection terminator <NUM>. To enable the secure proxy <NUM> to detect the sensitive data, the request may be in a structured format such as HTTP POST, multi-part POST, JSON, XML, or other format including a token or field that can be detected and indicate an owner. Then data protection module can encrypt or decrypted based at least in part on information indicating the owner of the data. For example, encrypting the data with the public key of the data or encrypting a symmetric key used to encrypt the data with the owner's private key and sending the encrypted symmetric key to the owner.

The content delivery network <NUM> may include one or more rack of servers executing an operating system with a run-time with process isolation and mandatory access controls to enforce security and protection of the sensitive data. In yet other embodiments, the content delivery network <NUM> may be executed by virtual hosts executing in a content delivery network environment, where each bare metal server is dedicated only to a single entity. In addition, with sufficient isolation at the hardware layer (e.g., dedicated racks and/or dedicated hosts), secure proxy <NUM> may be executed in a container instance.

<FIG> illustrates an environment <NUM> in which a secure proxy <NUM> connected with a content delivery network <NUM> receives sensitive data from a customer <NUM> and encrypts the sensitive data prior to transmitting the sensitive data to one or more back end services <NUM> in accordance with an embodiment. The content delivery network <NUM> establish a connection with the secure proxy <NUM> to enable the backend services <NUM>, implemented by a computing resource service provider as described above, to communicate with the customers <NUM>. The backend services <NUM> may be operated by the computing resource service provider or other entities. For example, the computing resource service provider may provide an organization with access to computing resources provided by the computing resource service provide to implement various services exposed to customers, such as a secure streaming media service. The computing resource service provider may also operate various networks, computing devices, services, applications, or other computing resources and provide customers and other entities access to perform various operations.

As illustrated in <FIG>, the one or more network <NUM> may include a variety of different networks implemented by various entities. For example, the one or more networks <NUM> may include a network backbone or other network structure that is part of a publicly addressable network such as the Internet. As described in greater detail below, the networks <NUM> may include public network, private network, content delivery networks, and other networks which may be implemented by different entities and/or services and may enforce different security policies and may be accessible by different entities and/or services.

The content delivery network <NUM> may be used to cache and serve high velocity content to customers <NUM> from a network location closer in geographic proximity and/or network proximity (e.g., number of network hops) to the customers <NUM>. The customer <NUM> may request content from backend services <NUM>, which may be executed within a data center, which may maintain all of the available content. The content device network <NUM> on the other hand may store or cache a portion of the available content closer to the customer <NUM> to reduce latency. Latency may be measured in Round Trip Time (RTT), therefore requests with increased frequently may reduce network cost and provide a better customer <NUM> experience to provide the content closer to the customer.

The content delivery network <NUM> may establish and terminate sessions using a connection terminator <NUM>. The connections may be established from the customer <NUM> to a network edge device (e.g., Point-of-Presence (POP) device). In various embodiments, the content and/or request transmitted between the network edge device and the customer <NUM> may be transmitted over a cryptographically protected communications channel such as TLS or SSL. The network edge device and the customer <NUM> may be mutually authenticated. Furthermore, the connection cryptographically protected communications channel such as a TLS connection may be a long lived session. As illustrated in <FIG>, the connection terminator <NUM> may also establish a connection with the secure proxy <NUM>. The secure proxy <NUM> may be executed by the computing resource service provider and may be connected to a network distinct from the content delivery network <NUM>.

The content delivery network <NUM> may be operated by an entity that is distinct from the customer <NUM> and the computing resource service provider. The connection terminator <NUM> may obtain requests from the customer <NUM> and decrypt the request as described above. This may expose a plain text representation of the request which may include sensitive data. The connection terminator <NUM> may then encrypt the request and transmit the request over a cryptographically protected communications channel to the secure proxy <NUM>. For example, the connection terminator <NUM> may establish a long live TLS connection with the secure proxy <NUM>. This may reduce the need to re-negotiate key material when transmitting data between the connection terminator <NUM> and the secure proxy <NUM>. In such embodiments, the secure proxy may execute its own TLS terminator not shown in <FIG> for simplicity. Furthermore, the secure proxy <NUM> may include a data protection module as described above. In various embodiments, the connection termination <NUM> decrypts the request from the customer and provides the request to the secure proxy <NUM>.

As described above, the data protection module may detect sensitive data and encrypt the sensitive data prior to transmitting the request to the backend services <NUM>. Furthermore, the computing resource service provider or service thereof such as the cryptographic key service may provide key material to the secure proxy <NUM>. The key material may be used to encrypt and decrypt sensitive data as described above. In addition, the key material may be sent separate from the secure proxy <NUM> obtaining a request from the connection terminator <NUM>. To enable the secure proxy <NUM> to detect the sensitive data, the request may be in a structured format such as HTTP POST, multi-part POST, JSON, XML, or other format including a token or field that can be detected and indicate an owner. Then the data protection module can encrypt or be decrypted based at least in part on information indicating the owner of the data. For example, encrypting the data with the public key of the data or encrypting a symmetric key used to encrypt the data with the owner's private key and sending the encrypted symmetric key to the owner.

In the environment illustrated in <FIG>, the process for securing sensitive data may be the same as described above with the addition of an added network hop between the content delivery network <NUM> and the secure proxy <NUM>. In some embodiments, the content delivery network includes a secure proxy <NUM> as described above in connection with <FIG>. In these embodiments, for an given request the content delivery network or process thereof may determine whether to process the request at the secure proxy executed within the content delivery network <NUM> or forward the request for processing to the secure proxy <NUM> executed by the computing resource service provider.

For example, if the content delivery network <NUM> encrypts the sensitive data, the content delivery network <NUM> can add a flag notifying downstream data protection modules that the sensitive data is protected and the data can be ignored. The content delivery network <NUM> may determine to encrypt the sensitive data in situations where exposure is unacceptable. In another example, the content delivery network <NUM> nay determine to encrypt the sensitive data based on data type associated with the sensitive data. Therefore, for data indicated as a less sensitive data type, the content delivery network <NUM> may forward the request including the sensitive data to the secure proxy <NUM> for protection. Encryption of the sensitive data by the content delivery network <NUM> may be performed using any of the mechanism described above.

In addition, the content delivery network <NUM> may also be used to provide data to the customer <NUM>. When providing encrypted sensitive data to the customer, the content delivery network <NUM> may parse requests, decrypt sensitive data, replace encrypted sensitive data with decrypted sensitive data as described above. However, in the case of the content delivery network <NUM> the data may be included in an unstructured format or stream of data. A flag or other marker included in the data may be used to indicate sensitive data, whether to decrypt the sensitive data, whether to ignore the sensitive data, whether to decrypt the sensitive data at the content delivery network <NUM> or inside the computing resource service provider environment, or any other indication of how to process the sensitive data.

<FIG> is a block diagram illustrating an example of a process <NUM> for protecting sensitive data directed to a backend service in accordance with an embodiment. The process <NUM> may be performed by any suitable system such as secure proxy fleet described above in connection with <FIG>. Some or all of the process <NUM> (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems including executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media).

The process <NUM> includes receiving a request for a cryptographically protected transmission <NUM>. The cryptographically protected transmission may include various methods of encrypting data to transmit the data over an unsecured network such as TLS or SSL. In addition, the request may be generated by an application executed by a client device in response to a customer interaction with the application. For example, the customer may use a web browser to navigate to a particular webpage. The request may be received at a secure proxy fleet or component thereof such as a connection terminator as described above. The secure proxy fleet or connection terminator may then establish the cryptographically protected transmission <NUM>. The cryptographically protected transmission may be established based at least in part on a protocol of algorithm as described above.

Once the cryptographically protected transmission is established, the secure proxy fleet may receive data over the cryptographically protected transmission <NUM>. The data may include requests, service calls, formatted and unformatted data (e.g., a data stream), or any other information that may be submitted by a customer to a backend service. The connection terminator may then decrypt the data <NUM>. For example, if the data includes an HTTPS request, the connection terminator may decrypt the encrypted data and generate an HTTP request. The secure proxy fleet or component thereof, such as a routing component, may then determine, based at least in part on the decrypted data, endpoint and routing information <NUM>. The endpoint and routing information may indicate a particular backend service and network path to direct the data. In addition, this information may be used to determine a particular data protection module of the secure proxy fleet to process data. As described above, the secure proxy fleet and/or data protection module may be configured for a single tenant (e.g., single backend service or exposed endpoint of a backend service) and as such may only process requests directed to the single tenant.

Returning to <FIG>, the system executing the process <NUM> may then provide the data to the data protection module <NUM>. The decrypted data may be streamed over a secure channel or otherwise provided to the data protection module. For example, the secure proxy fleet may provide the decrypted data to the data protection module over a UNIX (RTM) domain socket. The data protection module may receive the data and select configuration options for the data <NUM>. The configuration options may be selected based at least in part on the configuration information described above. For example, the data protection module may select a format for the data, such as a request format, and an encryption key to use to encrypt sensitive data.

The data protection module may then encrypt data based at least in part on the configuration operations <NUM>. The data protection module may only encrypt sensitive data indicated by the configuration options. As described above, the data protection module may us a cryptographic key service to perform various operations of the encryption workflow. The secure proxy fleet may then transmit the encrypted data to the endpoint over one or more intermediaries <NUM>. The intermediaries may include various networks and computer systems as described above. Furthermore, the encrypted data may be inserted into a request to the backend service and transmitted to an endpoint associated with the backend service.

Note that one or more of the operations performed in <NUM>-<NUM> may be performed in various orders and combinations, including in parallel. For example, in some embodiments the operations <NUM>-<NUM> may be omitted and the secure proxy may simply receive plaintext data from a client device. Furthermore, in some implementations the secure proxy fleet may maintain a plurality of data protection modules and/or multiple proxies; in such cases, multiple instances of the process <NUM> may be executing in parallel at the secure proxy fleet.

<FIG> is a block diagram illustrating an example of a process <NUM> for protecting sensitive data directed from a backend service to a client device in accordance with an embodiment. The process <NUM> may be performed by any suitable system such as secure proxy fleet described above in connection with <FIG>. Some or all of the process <NUM> (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems including executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media).

The process <NUM> includes, receiving a request for data <NUM>. The requests may be received from a client device operated by a customer, another service of a computing resource service provider, or third party. For example, the customer may request access to a first service, which may in turn request sensitive data from the backend service to include in a response by the first service to the customer. The backend service may then determine the data is sensitive data <NUM>. The backend service may determine the data is sensitive based at least in part on a category or type associated with the data. As a result, the backend service may encrypt the sensitive data <NUM>. Any number of encryption algorithms and standards may be used to protect the sensitive data as described above. For example, the backend service may use digital envelope encryption to protect a cryptographic key used to encrypt the sensitive data.

The backend service may then transmit a data stream including the encrypted data to an endpoint <NUM>. The data stream may be directed, redirected, and/or intercepted by the secure proxy fleet. In addition, the one or more intermediaries as described above may obtain and modify the data stream. For example, a rendering fleet may obtain the data stream and generate HTML based at least in part on the data included in the data stream. The secure proxy fleet may then receive the data stream <NUM>. The secure proxy fleet may be integrated with a content delivery network or may be executed using computing resources of the computing resource service provider.

The secure proxy fleet may then detect encrypted data <NUM>. The encrypted data may be detected based at least in part on a flag or marker included in the data stream as described above. The secure proxy fleet or component thereof, such as a rendering module, may then render the data stream <NUM>. Rendering the data stream may include any number of operations to process and organize the data for consumption by the client device. For example, rendering the data may include removing any executable code from the data. The secure proxy fleet or component thereof, such as a decryption module, may then decrypt the data <NUM>. The data may be decrypted using an encryption key which may be stored in memory of the secure proxy fleet or obtained from a cryptographic key service as described above.

The secure proxy fleet may then insert the decrypted data into a rendered data stream <NUM>. The rendered data stream may include data organized for consumption by a particular client device and directed to the particular client device. For example, the rendered data stream may include webpage content requests by the customer. Inserting the decrypted data may include overwriting the encrypted data with the decrypted data in the rendered data stream. The secure proxy fleet may then transmit the rendered data stream to the endpoint <NUM>. For example, the secure proxy fleet may transmit the rendered data fleet to the customer over the Internet using an IP address associated with the customer.

Note that one or more of the operations performed in <NUM>-<NUM> may be performed in various orders and combinations, including in parallel. For example, in some embodiments the operations <NUM>-<NUM> may be omitted and the secure proxy may simply receive encrypted data. Furthermore, in some implementations the secure proxy fleet may maintain a plurality of data protection modules and/or multiple proxies; in such cases, multiple instances of the process <NUM> may be executing in parallel at the secure proxy fleet.

<FIG> is a block diagram illustrating an example of a process <NUM> for protecting sensitive data by a data protection module in accordance with an embodiment. The process <NUM> may be performed by any suitable system such as data protection module described above in connection with <FIG>. Some or all of the process <NUM> (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems including executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media).

The process <NUM> includes obtaining configuration information <NUM>. The configuration information may be obtained from a backend service as described above and may contain information suitable for protecting sensitive data and communication with the backend service. For example, the configuration information may include a public key of the backend service and a request format associated with the backend service. The data protection module may then receive a request including plaintext data from a connection terminator <NUM>. The request may be forwarded or otherwise provided from a secure proxy fleet or edge network device as described above. The request may include any number of requests including and HTTP request or service request.

The data protection module may then determine if the request includes sensitive data <NUM>. The data protection module may detect sensitive data based at least in part on the configuration information and may be indicated by a flag or data type as described above. If the request does not include sensitive data the data protection module or secure proxy fleet may transmit the request to the endpoint <NUM>. However, if the data protection module detects sensitive data, the data protection module may provide the sensitive data to an encryption module <NUM>. The encryption module may be a separate process executed by the secure proxy fleet as described above. The encryption module may also interact with a cryptographic key service to encrypt the sensitive data.

The data protection module may then receive encrypted sensitive data from the encryption module <NUM>. The data protection module may then format a request to the backend service <NUM>. The request may be formatted based at least in part on the configuration information. Once the request is formatted the data protection module may replace the plaintext sensitive data with the encrypted sensitive data <NUM>. This may request in a modified request. The data protection module may then transmit the request to an endpoint associated with the backend service <NUM>.

Note that one or more of the operations performed in <NUM>-<NUM> may be performed in various orders and combinations, including in parallel. For example, in some embodiments the operations <NUM>-<NUM> may be omitted and data protection module may simply encrypt all the data provided to the data protection module. Furthermore, in some implementations the secure proxy fleet may maintain data protection modules and/or multiple proxies; in such cases, multiple instances of the process <NUM> may be executing in parallel at the secure proxy fleet.

<FIG> is a block diagram illustrating an example of a process <NUM> for performing key management for a secure proxy fleet in accordance with an embodiment. The process <NUM> may be performed by any suitable system such as cryptographic key management service described above in connection with <FIG>. Some or all of the process <NUM> (or any other processes described, or variations and/or combinations of those processes) may be performed under the control of one or more computer systems including executable instructions and/or other data, and may be implemented as executable instructions executing collectively on one or more processors. The executable instructions and/or other data may be stored on a non-transitory computer-readable storage medium (e.g., a computer program persistently stored on magnetic, optical, or flash media).

The process <NUM> includes receiving key materials <NUM>. As described above, the cryptographic key management service may execute a kernel level application on the secure proxy fleet which may periodically or aperiodically receive key materials. The cryptographic key management service may then receive a request to encrypt sensitive data <NUM>. The request may be obtained from a data protection module or encryption module as described above. The cryptographic key management service may then encrypt the sensitive data with a symmetric key <NUM>. The symmetric key may be generated by the system executing the process <NUM> or may be obtained from the key materials.

Furthermore, the cryptographic key management service may generate verification information <NUM>. The verification information may include a timestamp or signature as described above. The cryptographic key management service may then determine endpoint key information <NUM>. The endpoint key information may include metadata or other information indicating a particular cryptographic key associated with the endpoint such as a public key. The cryptographic key management service may then encrypt the symmetric key with the endpoint key <NUM>. For example, the cryptographic key management service may encrypt the symmetric key with a key only accessible to the endpoint.

The cryptographic key management service may then return the encrypted data <NUM>. The encrypted data may be returned to the data protection module or other component of the secure proxy fleet. In addition, the encrypted data may include the encrypted sensitive data, the encrypted symmetric key, and the verification information. Note that one or more of the operations performed in <NUM>-<NUM> may be performed in various orders and combinations, including in parallel. For example, in some embodiments the operation <NUM> may be omitted and the cryptographic key management service may simply encrypt the sensitive data without generating verification information.

<FIG> illustrates aspects of an example environment <NUM> for implementing aspects in accordance with various embodiments. As will be appreciated, although a web-based environment is used for purposes of explanation, different environments may be used, as appropriate, to implement various embodiments. The environment includes an electronic client device <NUM>, which can include any appropriate device operable to send and/or receive requests, messages, or information over an appropriate network <NUM> and, in some embodiments, convey information back to a user of the device. Examples of such client devices include personal computers, cell phones, handheld messaging devices, laptop computers, tablet computers, set-top boxes, personal data assistants, embedded computer systems, electronic book readers, and the like. The network can include any appropriate network, including an intranet, the Internet, a cellular network, a local area network, a satellite network, or any other such network and/or combination thereof. Components used for such a system can depend at least in part upon the type of network and/or environment selected. Many protocols and components for communicating via such a network are well known and will not be discussed herein in detail. Communication over the network can be enabled by wired or wireless connections and combinations thereof. In this example, the network includes the Internet and/or other publicly addressable communications network, as the environment includes a web server <NUM> for receiving requests and serving content in response thereto, although for other networks an alternative device serving a similar purpose could be used as would be apparent to one of ordinary skill in the art.

The illustrative environment includes at least one application server <NUM> and a data store <NUM>. It should be understood that there can be several application servers, layers or other elements, processes or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. Servers, as used herein, may be implemented in various ways, such as hardware devices or virtual computer systems. In some contexts, servers may refer to a programming module being executed on a computer system. As used herein, unless otherwise stated or clear from context, the term "data store" refers to any device or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media, in any standard, distributed, virtual or clustered environment. The application server can include any appropriate hardware, software and firmware for integrating with the data store as needed to execute aspects of one or more applications for the client device, handling some or all of the data access and business logic for an application. The application server may provide access control services in cooperation with the data store and is able to generate content including, but not limited to, text, graphics, audio, video and/or other content usable to be provided to the user, which may be served to the user by the web server in the form of HyperText Markup Language ("HTML"), Extensible Markup Language ("XML"), JavaScript, Cascading Style Sheets ("CSS"), JavaScript Object Notation (JSON), and/or another appropriate client-side structured language. Content transferred to a client device may be processed by the client device to provide the content in one or more forms including, but not limited to, forms that are perceptible to the user audibly, visually, and/or through other senses. The handling of all requests and responses, as well as the delivery of content between the client device <NUM> and the application server <NUM>, can be handled by the web server using PHP: Hypertext Preprocessor ("PHP"), Python, Ruby, Perl, Java, HTML, XML, JSON, and/or another appropriate server-side structured language in this example. Further, operations described herein as being performed by a single device may, unless otherwise clear from context, be performed collectively by multiple devices, which may form a distributed and/or virtual system.

The data store <NUM> can include several separate data tables, databases, data documents, dynamic data storage schemes and/or other data storage mechanisms and media for storing data relating to a particular aspect of the present disclosure. For example, the data store illustrated may include mechanisms for storing production data <NUM> and user information <NUM>, which can be used to serve content for the production side. The data store also is shown to include a mechanism for storing log data <NUM>, which can be used for reporting, analysis or other such purposes. It should be understood that there can be many other aspects that may need to be stored in the data store, such as page image information and access rights information, which can be stored in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store <NUM>. The data store <NUM> is operable, through logic associated therewith, to receive instructions from the application server <NUM> and obtain, update or otherwise process data in response thereto. The application server <NUM> may provide static, dynamic, or a combination of static and dynamic data in response to the received instructions. Dynamic data, such as data used in web logs (blogs), shopping applications, news services, and other such applications may be generated by server-side structured languages as described herein or may be provided by a content management system ("CMS") operating on, or under the control of, the application server. In one example, a user, through a device operated by the user, might submit a search request for a certain type of item. In this case, the data store might access the user information to verify the identity of the user and can access the catalog detail information to obtain information about items of that type. The information then can be returned to the user, such as in a results listing on a web page that the user is able to view via a browser on the user device <NUM>. Information for a particular item of interest can be viewed in a dedicated page or window of the browser. It should be noted, however, that embodiments of the present disclosure are not necessarily limited to the context of web pages, but may be more generally applicable to processing requests in general, where the requests are not necessarily requests for content.

Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed (i.e., as a result of being executed) by a processor of the server, allow the server to perform its intended functions.

The environment, in one embodiment, is a distributed and/or virtual computing environment utilizing several computer systems and components that are interconnected via communication links, using one or more computer networks or direct connections. However, it will be appreciated by those of ordinary skill in the art that such a system could operate equally well in a system having fewer or a greater number of components than are illustrated in <FIG>. Thus, the depiction of the system <NUM> in <FIG> should be taken as being illustrative in nature and not limiting to the scope of the disclosure.

The various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of computers, such as desktop, laptop, or tablet computers running a standard operating system, as well as cellular, wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system also can include a number of workstations running any of a variety of commercially-available operating systems and other known applications for purposes such as development and database management. These devices also can include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network. These devices also can include virtual devices such as virtual machines, hypervisors and other virtual devices capable of communicating via a network.

Various embodiments of the present disclosure utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially-available protocols, such as Transmission Control Protocol/Internet Protocol ("TCP/IP"), User Datagram Protocol ("UDP"), protocols operating in various layers of the Open System Interconnection ("OSI") model, File Transfer Protocol ("FTP"), Universal Plug and Play ("UpnP"), Network File System ("NFS"), Common Internet File System ("CIFS"), and AppleTalk. The network can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, a satellite network, and any combination thereof. In some embodiments, connection-oriented protocols may be used to communicate between network endpoints. Connection-oriented protocols (sometimes called connection-based protocols) are capable of transmitting data in an ordered stream. Connection-oriented protocols can be reliable or unreliable. For example, the TCP protocol is a reliable connection-oriented protocol. Asynchronous Transfer Mode ("ATM") and Frame Relay are unreliable connection-oriented protocols. Connection-oriented protocols are in contrast to packet-oriented protocols such as UDP that transmit packets without a guaranteed ordering.

In embodiments utilizing a web server, the web server can run any of a variety of server or mid-tier applications, including Hypertext Transfer Protocol ("HTTP") servers, FTP servers, Common Gateway Interface ("CGI") servers, data servers, Java servers, Apache servers, and business application servers. The server(s) also may be capable of executing programs or scripts in response to requests from user devices, such as by executing one or more web applications that may be implemented as one or more scripts or programs written in any programming language, such as Java°, C, C# or C++, or any scripting language, such as Ruby, PHP, Perl, Python or TCL, as well as combinations thereof. The server(s) may also include database servers, including without limitation those commercially available from Oracle°, Microsoft°, Sybase°, and IBM® as well as open-source servers such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving, and accessing structured or unstructured data. Database servers may include table-based servers, document-based servers, unstructured servers, relational servers, non-relational servers, or combinations of these and/or other database servers.

The environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network ("SAN") familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices may be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit ("CPU" or "processor"), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad) and at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as random access memory ("RAM") or read-only memory ("ROM"), as well as removable media devices, memory cards, flash cards, etc..

Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed, and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or web browser. In addition, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets) or both.

Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules or other data, including RAM, ROM, Electrically Erasable Programmable Read-Only Memory ("EEPROM"), flash memory or other memory technology, Compact Disc Read-Only Memory ("CD-ROM"), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices or any other medium which can be used to store the desired information and which can be accessed by the system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.

As discussed above, numerous cryptographic techniques may be used. numerous variations utilize symmetric and/or asymmetric cryptographic primitives. Symmetric key algorithms may include various schemes for performing cryptographic operations on data including block ciphers, stream ciphers and digital signature schemes. Example symmetric key algorithms include the advanced encryption standard (AES), the data encryption standard (DES), triple DES (3DES), Serpent, Twofish, blowfish, CAST5, RC4 and the international data encryption algorithm (IDEA). Symmetric key algorithms may also include those used to generate output of one way functions and include algorithms that utilize hash-based message authentication codes (HMACs), message authentication codes (MACs) in general, PBKDF2 and Bcrypt. Asymmetric key algorithms may also include various schemes for performing cryptographic operations on data. Example algorithms include those that utilize the Diffie-Hellman key exchange protocol, the digital signature standard (DSS), the digital signature algorithm, the ElGamal algorithm, various elliptic curve algorithms, password-authenticated key agreement techniques, the pallier cryptosystem, the RSA encryption algorithm (PKCS#<NUM>), the Cramer-Shoup cryptosystem, the YAK authenticated key agreement protocol, the NTRUEncrypt cryptosystem, the McEliece cryptosystem, and others. Elliptic curve algorithms include the elliptic curve Diffie-Hellman (ECDH) key agreement scheme, the Elliptic Curve Integrated Encryption Scheme (ECIES), the Elliptic Curve Digital Signature Algorithm (ECDSA), the ECMQV key agreement scheme and the ECQV implicit certificate scheme. Other algorithms and combinations of algorithms are also considered as being within the scope of the present disclosure and the above is not intended to be an exhaustive list. Other Example cryptographic algorithms include block ciphers and the various modes that utilize initialization vectors, such as the cipher-block chaining (CBC) mode, propagating cipher-block chaining (PCBC) mode, cipher feedback mode (CFB), output feedback (OFB) mode, counter (CTR) mode, and other modes, such as authenticated encryption modes such as extended Ciphertext Block Chaining (XCBC) mode, Integrity Aware CBC (IACBC) mode, Integrity Aware Parallelizable (IAPM) mode, Offset Codebook (OCB) mode, EAX and EAX Prime modes, Carter-Wegman + CTR (CWC) mode, Counter with CBC-MAC (CCM) mode, Galois/Counter (GCM) mode. Generally, embodiments of the present disclosure may use various protocols, such as a SSL or TLS protocol and extensions thereto, such as defined in Request for Comments (RFC) <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, and RFC <NUM> which are incorporated herein by reference, to establish encrypted communications sessions. Other protocols implemented below the application layer of the Open Systems Interconnect (OSI) model may also be used and/or adapted to utilize techniques described herein. It should be noted that the techniques described herein are adaptable to other protocols such as the Real Time Messaging Protocol (RTMP), the Point-to-Point Tunneling Protocol (PPTP), the Layer <NUM> Tunneling Protocol, various virtual private network (VPN) protocols, Internet Protocol Security (e.g., as defined in RFC <NUM> through <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, RFC <NUM>, and RFC <NUM>) and other protocols, such as protocols for secure communication that include a handshake.

Certain illustrated embodiments of the disclosed techniques are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed.

Operations of processes described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. Processes described herein (or variations and/or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors, by hardware or combinations thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory. In some embodiments, the code is stored on set of one or more non-transitory computer-readable storage media having stored thereon executable instructions that, when executed (i.e., as a result of being executed) by one or more processors of a computer system, cause the computer system to perform operations described herein. The set of non-transitory computer-readable storage media may comprise multiple non-transitory computer-readable storage media and one or more of individual non-transitory storage media of the multiple non-transitory computer-readable storage media may lack all of the code while the multiple non-transitory computer-readable storage media collectively store all of the code. Further, in some examples, the executable instructions are executed such that different instructions are executed by different processors. As an illustrative example, a non-transitory computer-readable storage medium may store instructions. A main CPU may execute some of the instructions and a graphics processor unit may execute other of the instructions. Generally, different components of a computer system may have separate processors and different processors may execute different subsets of the instructions.

Claim 1:
A system, comprising:
at least one computing device (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) implementing one or more services and one or more backend services (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), wherein the one or more services:
receive, over a cryptographically protected communications session, a set of data objects directed towards the one or more backend services (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), where the one or more backend services (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) expose one or more endpoints for various types of sensitive data;
determine that a subset of data objects of the set of the data objects includes sensitive data based at least in part on configuration information provided by the one or more backend services (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), wherein the configuration information comprises information suitable for identifying sensitive data, thereby enabling detection of sensitive data, indicates an endpoint to transmit sensitive data based at least in part on a type associated with the sensitive data, and indicates a cryptographic key associated with the endpoint;
determine, based at least in part on a type of sensitive data, an endpoint to which to transmit the sensitive data, and a cryptographic key associated with said endpoint;
obfuscate the subset of data objects, using the determined cryptographic key, to generate a set of encrypted data objects which can be decrypted by the one or more backend services (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) that expose the endpoint;
modify the set of data objects to include the set of encrypted data obj ects, together with a flag or marker to indicate the presence of encrypted data objects, thereby generating a modified set of data objects; and
transmit the modified set of data objects to the endpoint exposed by the one or more backend services (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>).