Cloud DNS Proxy and AHID Isolation Against Cross-Account Data Exfiltration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Malicious apps can exfiltrate user data by using Trojan session tokens to transfer data from a consumer's account to a producer's internal stage in cloud data platforms, posing a security risk.
Innovation Solution
Implement a multi-layer defense system with unique block-storage hostnames per account, DNS proxy to limit hostname resolution, and SNI filtering to ensure secure data access, using Account Host Identifiers (AHID) and Extended Berkeley Packet Filter (EBPF) to validate TLS handshakes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If internal stages are shared across multiple accounts for data storage, then data accessibility and platform versatility are improved, but security risks increase due to potential unauthorized data transfer between accounts
Solution Approach 1:
The system segments the shared storage space by creating account-specific namespaces within internal stages. Each account receives a unique identifier that is prepended to all stage names, effectively partitioning the shared storage into isolated logical sections. This allows multiple accounts to access the same physical storage infrastructure while preventing unauthorized cross-account data transfer, as malicious code cannot guess or access stage names belonging to other accounts.
Solution Approach 2:
The system introduces an intermediary layer (the account identifier prefix) between the user-facing stage names and the actual storage locations. This intermediary ensures that all data access requests are automatically routed through account-specific naming conventions, providing built-in protection against unauthorized access while maintaining efficient access to legitimate data.
2Reliability
If unique hostnames are implemented per account for TLS verification, then security against data exfiltration is improved, but system complexity increases due to additional hostname management
Solution Approach 1:
The system merges the account identifier (which already exists for authentication and stage naming purposes) with the hostname generation process. By reusing the existing account identifier to construct unique hostnames, the system avoids creating a separate identity management mechanism, thereby reducing overall complexity while still providing unique TLS verification credentials for each account.
Solution Approach 2:
The account identifier serves multiple functions simultaneously: it authenticates users, names internal stages, and generates unique hostnames for TLS verification. This multi-functionality eliminates the need for separate hostname management infrastructure, reducing system complexity while maintaining strong security through unique per-account hostnames.
Data Source
AI summary
A system is disclosed comprising a memory containing instructions and one or more computer processors. When the instructions are executed, the system performs an operation to configure a Domain Name System (DNS) proxy, executing in a node of a cloud data platform associated with a first account, to perform hostname resolution of an Account Host Identifier (AHID) of the first account. The DNS proxy receives a DNS request from a process executing in a pod of the node, and the system fails to resolve the DNS request if the name in the DNS request differs from the AHID of the first account. The system returns an Internet Protocol (IP) address if the name in the DNS request matches the AHID. The process executing in the pod of the node is configured to send data to data storage of the cloud data platform using the returned IP address.