AWS wellarchitected high security documentation change
Summary
Added guidance for SageMaker AI HyperPod security configurations, updated terminology (RAG to include generative BI), enhanced access control recommendations, and added related documentation links
Security assessment
The changes add specific security controls for SageMaker AI HyperPod workloads including IAM role granularity, pod security via IRSA, Slurm permissions, and audit requirements. These are security-focused access control measures designed to prevent unauthorized data exposure. The additions explicitly mention reducing 'risk of accidental or malicious data exposure' and reference encryption/data protection documentation.
Diff
diff --git a/wellarchitected/latest/generative-ai-lens/gensec01-bp03.md b/wellarchitected/latest/generative-ai-lens/gensec01-bp03.md index 45fdedcae..d2fccd3e6 100644 --- a//wellarchitected/latest/generative-ai-lens/gensec01-bp03.md +++ b//wellarchitected/latest/generative-ai-lens/gensec01-bp03.md @@ -30 +30 @@ Foundation models can aggregate and generate rich insights from data they have b -Generative AI architecture patterns like Retrieval Augmented Generation (RAG) make use of external data to correlate with the foundation models output and address user prompts. In many cases, a single vector database may store data intended for several use cases, some of which require additional authorizations to access. While controls can be implemented at the foundation model layer, this approach alone is insufficient. Addressing access to data requires a multi-layered strategy. This is necessary not only for RAG use cases but also for model customization and pre-training processes. +Generative AI architecture patterns like Retrieval Augmented Generation (RAG) or generative business intelligence (BI) use external data to correlate with the foundation models output and address user prompts. In many cases, a single vector database may store data intended for several use cases, some of which require additional authorizations to access. While controls can be implemented at the foundation model layer, this approach alone is insufficient. Addressing access to data requires a multi-layered strategy. This is necessary not only for RAG use cases but also for model customization and pre-training processes. @@ -34 +34 @@ When securing foundation models and protecting sensitive data, customers should -When using data for model training, especially in generative AI scenarios, applying robust data obfuscation and anonymization techniques can prevent unintended exposure of sensitive data through model outputs. Vector databases supported with services such as Amazon OpenSearch Service offers efficient ways to sanitize and manage large-scale data for AI workloads, improving both performance and security. At the application layer, customers should regularly review and refine Access Control Lists to prevent unauthorized access to data. Utilizing metadata filtering capabilities in vector stores and knowledge bases can enable more granular access control, allowing for data segregation based on user roles or project requirements. For Identity and Access Management, creating IAM roles with precision, such as attribute based access controls, helps maintain the principle of least privilege. Designing IAM policy documents with properly scoped permissions can help prevent improper access. Amazon Bedrock Knowledge Bases can add a layer of abstraction to data access, simplifying permission management across multiple data sources. +When using data for model training, especially in generative AI scenarios, applying robust data obfuscation and anonymization techniques can avoid unintended exposure of sensitive data through model outputs. Vector databases supported with services such as Amazon OpenSearch Service offers efficient ways to sanitize and manage large-scale data for AI workloads, improving both performance and security. At the application layer, customers should regularly review and refine Access Control Lists to stop unauthorized access to data. Utilizing metadata filtering capabilities in vector stores and knowledge bases can enable more granular access control, allowing for data segregation based on user roles or project requirements. For Identity and Access Management, creating IAM roles with precision, such as attribute based access controls, helps maintain the principle of least privilege. Designing IAM policy documents with properly scoped permissions can help stop improper access. Amazon Bedrock Knowledge Bases can add a layer of abstraction to data access, simplifying permission management across multiple data sources. @@ -37,0 +38,8 @@ When designing the overall architecture, aligning data access permissions with d +When using Amazon SageMaker AI HyperPod on both Amazon EKS and Slurm, assign IAM roles to each workload or user that grant only the specific permissions needed to access required data stores, such as S3 buckets or databases. + +For Amazon EKS, use Kubernetes service accounts mapped to IAM roles (IRSA) to verify that pods have only the minimum access needed. + +In Slurm, configure IAM roles for each compute group or job, and restrict permissions to only the necessary resources. + +Regularly audit these roles and policies using tools like AWS IAM Access Analyzer and update them as requirements evolve. Apply resource-level policies on S3 buckets and databases to further limit access, and use security groups to control network communication between nodes and data sources. Verify that both users and foundation models in SageMaker AI HyperPod clusters can only access the data they are explicitly authorized for, reducing the risk of accidental or malicious data exposure. + @@ -42 +50 @@ When designing the overall architecture, aligning data access permissions with d - 2. Deploy a vector data store into a secure VPC, setting appropriate access controls on the datastore for various roles (for example, administrator, read-only, or power-user). Consider extending role definitions to encompass generative AI workloads (like `model-XX-RAG`). + 2. Deploy a vector data store into a secure VPC, setting appropriate access controls on the datastore for various roles (for example, administrator, read-only, or power-user). Consider extending role definitions to encompass generative AI workloads (like model-XX-RAG). @@ -61 +69 @@ When designing the overall architecture, aligning data access permissions with d -**Related practices:** +**Related best practices:** @@ -76 +84 @@ When designing the overall architecture, aligning data access permissions with d -**Related guides, videos, and documentation:** +**Related documents:** @@ -89,0 +98,4 @@ When designing the overall architecture, aligning data access permissions with d + * [Protect Data at Rest Using Encryption](https://docs.aws.amazon.com/sagemaker/latest/dg/encryption-at-rest.html) + + * [Data Protection in Amazon SageMaker AI](https://docs.aws.amazon.com/sagemaker/latest/dg/data-protection.html) +