Skip to content

securityGuide.md

Latest commit

 

History

History
561 lines (375 loc) · 24.3 KB

securityGuide.md

File metadata and controls

561 lines (375 loc) · 24.3 KB
Raw

Security Documentation & Network Architecture

Shared Responsibility Model

Shared Responsibility Model

Customer Responsibilities (Security in the Cloud):

  • Data Protection
  • Identity & Access Management
  • Application Security
  • Network Security Configuration:

Learn more

This document outlines the existing network and security configurations implemented for this project. Additionally, it provides recommendations and guidance on leveraging AWS services and features to enhance security, monitor application performance, and maintain compliance

1. Network Architecture

Network Architecture Diagram

1.1 VPC & Subnets

VPC Configuration:

  • Leveraged existing VPC in AWS Account since organizational policies prevent new VPC creation
  • CIDR Range is inherited from existing VPC configuration

Subnet Configuration:

Subnet Type AZ Key Services
Private ca-central-1a Lambda
Private ca-central-1b RDS Proxy, Amazon RDS
Public ca-central-1 NAT Gateway, Internet Gateway

Services Deployment:

Private Subnets:

  • AWS Lambda:

    • Runtime environment for application logic
    • No public IP addresses
    • Outbound internet via NAT Gateway

  • Amazon RDS (PostgreSQL):

    • Accessed exclusively via RDS Proxy
    • No direct public access
    • Encrypted connections via SSL/TLS

    Since VPC Endpoints are not used, Lambda accesses S3, ECR, and other AWS services over the public internet through the NAT Gateway.

Public Subnets:

  • NAT Gateway: Learn more

    • Required for private subnet services to fetch external packages/updates
    • Egress-only internet access for Lambda
    • Cost-optimized single AZ deployment

  • Internet Gateway: Learn more

    • Enables public access to API Gateway

Services outside of VPC:

  • S3 Buckets: Learn more

    • Accessed via NAT Gateway through Lambda functions
    • No internet routing through NAT Gateway

    How objects in S3 are accessed:

    S3 Workflow Diagram

    The above diagram illustrates the use of S3 pre-signed URLs in our architecture. The process works as follows:

    1. Client Request: The client first requests a pre-signed URL by making an API call to the Amazon API Gateway

    2. Pre-Signed URL Generation: The API Gateway invokes an AWS Lambda function, which is responsible for generating the pre-signed URL. The Lambda function checks for the appropriate permissions (PutObject action) for the requested S3 bucket

    3. Permission Validation: If permissions are validated, the Lambda function returns the generated pre-signed URL to the client

    4. File Upload: The client uses this pre-signed URL to upload files directly to S3, bypassing the need for the server to handle large file uploads. This approach ensures:

      • Secure, time-limited access to the S3 bucket without exposing long-term credentials

      • Offloading file transfer workload from backend servers, reducing latency and cost

    Learn More:

    Additional security measures:

    • All data is encrypted at rest using SSE-S3 (AES-256)
    • Public access is blocked for all S3 buckets
    • SSL connections are enforced for secure data transfer

  • Amazon API Gateway:

    • Deployed in AWS public cloud space
    • Protected by regional security controls
    • Custom Lambda Authorizers validate user permissions before accessing endpoints for 3 different roles
    • Uses Cognito User Pools for authentication and role-based access control
    • IAM policies restrict API Gateway access based on user roles

  • Amazon Bedrock:

    • Provides foundation models for RAG (Retrieval-Augmented Generation) functionality
    • Requires explicit model access requests for utilization
    • API interactions secured using IAM roles and encrypted connections
    • Used for text generation and embedding creation in research workflows
    • All model invocations are logged and monitored via CloudWatch

  • AWS AppSync:

    • Provides real-time data queries and synchronizes data between clients and backend
    • Integrated with IAM for authentication and runs in the public cloud space
    • Only specific Lambda functions are granted permissions to send or receive messages

  • Amazon Cognito:

    • Provides authentication and authorization for Lambda access
    • Role-based access control via IAM roles and policies
    • Triggers (Pre-Sign-Up, Post-Confirmation, Post-Authentication) manage user provisioning.
    • Secures real-time data sync via AppSync with Lambda authorizers

  • Amazon ECR:

    • Lambda functions utilize Docker images stored in Amazon ECR
    • Images are securely pulled over the internet via the NAT Gateway

1.2 Security Configuration

Security Configuration

This diagram illustrates how our architecture handles key security aspects by leveraging AWS services tailored for each security domain. Identity Services, including AWS IAM and Amazon Cognito, ensure secure authentication and access control. Data Protection is enforced through AWS Secrets Manager and AWS KMS for secure storage and encryption. Infrastructure Protection relies on AWS WAF, AWS Shield, and AWS Systems Manager to safeguard against threats. Detection Services such as Security Hub, Amazon GuardDuty, and Amazon CloudWatch provide continuous monitoring and threat detection

2. Security Controls

2.1 Network Security

Security Groups:

Name Rules
Lambda-SG Allow outbound: 5432 (RDS Proxy)
RDS-Proxy-SG Allow inbound: 5432 from Lambda-SG
Default-SG Block all inbound, allow outbound

NACLs:

  • Default NACLs in use
  • No custom rules - inherits Control Tower baseline:
    • Inbound: ALLOW ALL
    • Outbound: ALLOW ALL

3. Data Store Security

3.1 Encryption

Purpose: Ensure all stored data is encrypted at rest to meet compliance and security standards

3.2 Access Controls

RDS Proxy:

  • IAM authentication required
  • Connection pooling limits credential exposure
  • Audit logs enabled via CloudWatch

4. Secrets & Parameters

4.1 Credential Management

Purpose: Securely manage sensitive credentials such as RDS passwords

AWS Secrets Manager:

  • Creates a new secret named DBSecret for RDS credentials
  • Enhances security by regularly updating credentials without manual intervention

5. Security Services

5.1 AWS WAF & Shield

WAF Rules Applied: Learn more

  • SQLi Protection (AWSManagedRulesSQLiRuleSet)
  • XSS Protection (AWSManagedRulesXSSRuleSet)
  • Request Threshold: 100 requests/min per IP

Shield Standard: Learn more

  • Enabled on API Gateway
  • CloudWatch alarms for DDoS detection

5.2 Security Hub

Purpose: Enable continuous security monitoring and automate compliance checks Learn more

Account-level monitoring recommendations:

  • Enable Security Hub in the AWS Management Console for the target region (e.g., ca-central-1)
  • Integrate Security Hub with AWS services (e.g., GuardDuty) for comprehensive security analysis
  • Use Security Hub Insights to identify and prioritize security issues across AWS accounts

How to Use:

  • Navigate to Security Hub in the AWS console
  • Review findings generated from AWS best practices and integrated security services
  • Apply security standards like AWS Foundational Security Best Practices
  • Use custom insights and filters (e.g., resources.tags.Project = "Research-Data-Insights") to focus on relevant resources
  • Remediate issues based on the severity and compliance requirements

6. RDS Security

6.1 RDS Encryption

Purpose: Secure RDS data at rest using AWS KMS encryption and prevent accidental deletion

  • Enabled storage encryption for storageEncrypted is set to true
  • Referenced an existing KMS key using kms.Key.fromKeyArn() for encryption
  • deletionProtection is set to true to prevent unintended RDS deletions.

6.2 RDS Security Groups

Purpose: Control database access by allowing PostgreSQL traffic (5432) only from trusted CIDRs

CDK Implementation:

vpcStack.privateSubnetsCidrStrings.forEach((cidr) => {
  dbSecurityGroup.addIngressRule(
    ec2.Peer.ipv4(cidr),
    ec2.Port.tcp(5432),
    `Allow PostgreSQL traffic from ${cidr}`
  );
});

6.3 RDS Proxy

Purpose: Purpose: Enhance RDS access performance, security, and scalability by utilizing Amazon RDS Proxy

  • IAM Authentication: RDS Proxy requires IAM authentication for secure access
  • Connection Pooling: Efficiently manages and reuses database connections, reducing the load on RDS
  • TLS Enforcement: Secure connections with optional TLS enforcement for data-in-transit encryption
  • Role Management: IAM roles grant rds-db:connect permissions to trusted Lambda functions
  • Fault Tolerance: Proxies automatically handle database failovers, improving application availability
  • Security Groups: Configured to allow only trusted Lambda functions and services within private subnets to connect

7. S3 Security

Bucket Security Configurations

Purpose: Ensure data confidentiality by encrypting S3 objects and blocking public access Learn more

  • Enabled S3-managed encryption (S3_MANAGED) for data at rest
  • Blocked all public access with blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL
  • Enforced SSL connections for secure data transfer by setting enforceSSL: true

CDK Implementation:

blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
enforceSSL: true, // Enforce secure data transfer
encryption: s3.BucketEncryption.S3_MANAGED,

8. Security Group Configurations

Purpose: Secure network access between AWS components, ensuring least-privilege access

8.1 Key Security Group Controls in CDK:

Component CDK Location Key Security Control Purpose
RDS DatabaseStack PostgreSQL (5432) only from private/VPC CIDRs Restricts DB access to internal networks
Lambda ApiGatewayStack IAM policies for Secrets and ENI management access Limits Lambda access to necessary resources
AppSync ApiGatewayStack Lambda authorizer & appsync:GraphQL permissions Ensures secure, authenticated access to GraphQL APIs
RDS Proxy DatabaseStack IAM-based rds-db:connect permissions Adds an extra layer of security between Lambda and RDS

8.2 Examples from CDK infrastructure where these security measures are implemented:

Lambda Access to Secrets Manager:

lambdaRole.addToPolicy(
  new iam.PolicyStatement({
    actions: ["secretsmanager:GetSecretValue"],
    resources: [
      `arn:aws:secretsmanager:${this.region}:${this.account}:secret:*`,
    ],
  })
);

Private Subnet Access: Allows PostgreSQL traffic (port 5432) only from private subnet CIDRs:

vpcStack.privateSubnetsCidrStrings.forEach((cidr) => {
  dbSecurityGroup.addIngressRule(
    ec2.Peer.ipv4(cidr),
    ec2.Port.tcp(5432),
    `Allow PostgreSQL traffic from private subnet CIDR range ${cidr}`
  );
});

Lambda Network Access: Enables Lambda to create network interfaces (ENIs) for VPC access

this.dbInstance.connections.securityGroups.forEach((securityGroup) => {
  securityGroup.addIngressRule(
    ec2.Peer.ipv4(vpcStack.vpcCidrString),
    ec2.Port.tcp(5432),
    "Allow PostgreSQL traffic from public subnets"
  );
});

Lambda Access to Secrets Manager:

lambdaRole.addToPolicy(
  new iam.PolicyStatement({
    effect: iam.Effect.ALLOW,
    actions: ["secretsmanager:GetSecretValue"],
    resources: [
      `arn:aws:secretsmanager:${this.region}:${this.account}:secret:*`,
    ],
  })
);

8.3 Lambda Function Access & Invocation

Summary of Lambda Function Access Learn more:

Lambda Function Access Level Trigger/Invocation Who Can Access?
memberFunction Private member Authenticated users in member group
researcherFunction Private researcher Authenticated users in researcher group
adminFunction Private admin Authenticated users in admin group
preSignupLambda Private Cognito Pre-Sign-Up trigger Cognito internal trigger only
postConfirmationLambda Private Cognito Post-Confirmation trigger Cognito internal trigger only
postAuthenticationLambda Private Cognito Post-Authentication trigger Cognito internal trigger only
textGenerationFunction Private researcher/member researcher or member group users
generatePresignedURLFunction Private researcher/member researcher or member group users
dataIngestionFunction Private researcher researcher group users
embeddingFunction Private researcher/member researcher or member group users
ragQueryFunction Private researcher/member researcher or member group users
adminLambdaAuthorizer Private API Gateway Lambda Authorizer (admin) Internal to API Gateway for auth checks
memberLambdaAuthorizer Private API Gateway Lambda Authorizer (member) Internal to API Gateway for auth checks
researcherLambdaAuthorizer Private API Gateway Lambda Authorizer (researcher) Internal to API Gateway for auth checks

9. Cognito User Authentication

9.1 Purpose

AWS Cognito provides user authentication and authorization, enabling secure access to Lambda functions based on user roles. By integrating Cognito with Lambda, we ensure that only authenticated users with the appropriate permissions can invoke Lambda functions, maintaining the principle of least privilege

Learn more

9.2 How Cognito Secures Lambda Invocations

  • User Pool Creation:
    Cognito User Pools manage user registration and sign-in

    • Supports multi-role user groups (e.g., member, researcher, admin)
    • Automatic verification of user credentials

  • Role-Based Access Control (RBAC):
    Cognito assigns IAM roles based on user groups, allowing fine-grained access control to specific Lambda functions.

    • Example roles: MemberRole, ResearcherRole, AdminRole
    • IAM policies attached to each role define permitted Lambda invocations

  • Lambda Integration:
    Cognito-generated JWT tokens are validated by Lambda authorizer functions to ensure:

    • Only authorized users can invoke specific Lambda endpoints
    • JWT tokens expire 30 days after a user signs in Learn more
    • Access is logged and monitored via CloudWatch

9.3 Cognito Integration in CDK (ApiGatewayStack)

User Pool & App Client Configuration:

const userPool = new cognito.UserPool(this, "UserPool", {
  signInAliases: { email: true },
  selfSignUpEnabled: true,
  userVerification: { emailStyle: cognito.VerificationEmailStyle.CODE },
  passwordPolicy: {
    minLength: 8,
    requireLowercase: true,
    requireUppercase: true,
  },
});

const appClient = userPool.addClient("AppClient", {
  authFlows: { userPassword: true, userSrp: true },
});

10 API Gateway Security

10.1 Purpose

AWS API Gateway acts as the entry point for clients, enabling secure, scalable, and managed API interactions. It integrates with AWS IAM, Cognito, and Lambda Authorizers to enforce authentication and authorization.

10.2 Security Measures Applied:

  • Cognito User Pools for authentication
  • IAM Policies to enforce least-privilege access
  • Lambda Authorizers for custom permission validation
  • AWS WAF to mitigate DDoS attacks and malicious traffic

Learn more

10.3 Custom Lambda Authorizer for API Gateway

Lambda Authorizers provide fine-grained access control by validating requests before they reach the API Gateway methods. This allows us to enforce custom authentication and authorization logic, such as role-based access control (RBAC) or JSON Web Token (JWT) validation

const lambdaAuthorizer = new apigateway.TokenAuthorizer(this, "LambdaAuth", {
  handler: myLambdaAuthorizer,
  identitySource: "method.request.header.Authorization",
});

const restrictedResource = api.root.addResource("restricted");
restrictedResource.addMethod(
  "POST",
  new apigateway.LambdaIntegration(myLambda),
  {
    authorizationType: apigateway.AuthorizationType.CUSTOM,
    authorizer: lambdaAuthorizer,
  }
);

Key Features of Lambda Authorizer:

  • Custom Authentication: Uses a Lambda function to validate JWT tokens or other credentials before granting access
  • Identity Source: Extracts authentication data from the Authorization header in HTTP requests
  • Granular Access Control: Ensures that only authorized users can access specific API methods

11. Vector Embeddings & pgvector Security

11.1 Purpose

The Research Data Insights platform uses vector embeddings stored in PostgreSQL with the pgvector extension to enable semantic search and RAG functionality. Security measures ensure embedding data integrity and access control.

11.2 Security Measures:

  • Embedding Isolation: Each research agenda's embeddings are isolated by research_agenda_id
  • Access Control: Only authorized researchers and members can query embeddings for their agendas
  • Data Encryption: Vector embeddings are encrypted at rest in RDS using KMS
  • Similarity Search Security: Vector similarity queries are restricted by user permissions
  • Metadata Protection: Embedding metadata is stored as encrypted JSONB fields

11.3 Research Agenda Security

Purpose: Ensure research agendas and their associated data are properly isolated and secured

  • Agenda Ownership: Each research agenda is owned by a researcher user
  • Collaborator Management: Only agenda owners can add/remove collaborators
  • Document Access Control: Context documents and observations are restricted to agenda members
  • Chat Session Isolation: Chat sessions are scoped to specific research agendas and users

12. AWS Systems Manager Security

12.1 Purpose

AWS Systems Manager (SSM) provides centralized management, automation, and security enforcement for AWS resources, helping secure access to infrastructure and maintain compliance through patching, logging, and configuration management

Amazon CloudWatch is used to monitor AWS resources, applications, and security logs. It plays a crucial role in performance monitoring Learn more

12.2 Security Measures:

  • Parameter Store Access Logs: Monitors access to sensitive configuration data, including secrets and API keys
  • Anomalous Parameter Store Access: Triggers alarms when unauthorized services or users attempt to retrieve sensitive parameters

13. RAG (Retrieval-Augmented Generation) Security

13.1 Purpose

The RAG system combines vector similarity search with Amazon Bedrock to provide contextually relevant responses. Security measures ensure data privacy and access control throughout the RAG pipeline.

13.2 Security Measures:

  • Context Isolation: RAG queries only access documents and observations within the user's research agenda
  • Prompt Injection Protection: User inputs are sanitized before being sent to Bedrock models
  • Response Tracking: All RAG interactions are logged with source document references
  • Model Access Control: Bedrock model access is restricted via IAM policies
  • Data Lineage: System tracks which documents contributed to each response for audit purposes

13.3 RAG Data Flow Security:

  1. Query Processing: User queries are validated and scoped to authorized research agendas
  2. Vector Search: Similarity search is performed only on user-accessible embeddings
  3. Context Assembly: Retrieved documents are filtered by user permissions
  4. LLM Invocation: Bedrock calls include only authorized context data
  5. Response Logging: All interactions are recorded for security monitoring

14 AWS Key Management Service (KMS)

13.1 Purpose

AWS KMS (Key Management Service) provides centralized encryption key management, helping to keep sensitive data encrypted both at rest and in transit. It integrates with multiple AWS services to offer scalable and automated encryption security Learn more

13.2 Security Measures:

  • KMS Key Access Logs: Records every use of an encryption key to help detect unauthorized decryption attempts
  • Excessive Key Usage: Triggers alerts if a specific key is accessed more than usual, potentially indicating a compromise

15. Amazon ECR

Purpose:
Amazon Elastic Container Registry (ECR) provides a secure, scalable private container registry. It integrates with AWS Identity and Access Management (IAM) and other AWS security services to protect container images

Learn more

Key Security Measures:

  1. Private Repositories

    • Images are stored privately; access is controlled by IAM and resource-based policies.
    • Learn more

  2. TLS Enforcement

    • All ECR API calls must use TLS 1.2 or higher, ensuring data in transit is secure.

  3. IAM Roles & Policies

    • There are permissions (e.g., ecr:GetAuthorizationToken, ecr:BatchGetImage) that control who can push/pull images.

  4. Lifecycle Policies

    • Automatically remove outdated images to minimize storage costs and reduce the attack surface.

  5. Image Scanning

    • All ECR repos have image scanning enabled to detect vulnerabilites and remediate issues.

Recommendation:

  • Regularly review ECR logs in AWS CloudTrail to identify suspicious or unauthorized access attempts
  • Implement lifecycle policies to retain only the most recent, patched images for better security and cost efficiency