All Resources
In this article:
minus iconplus icon
This is some text inside of a div block.
Share the Article
Copy to clipboard

AWS Security Groups: Best Practices, EC2, & More

November 1, 2023
8
 Min Read
Data Security
Author Image
Ron Reiter
Co-Founder and CTO
linkedin logotwitter logo

What are AWS Security Groups?

AWS Security Groups are a vital component of AWS's network security and cloud data security. They act as a virtual firewall that controls inbound and outbound traffic to and from AWS resources. Each AWS resource, such as Amazon Elastic Compute Cloud (EC2) instances or Relational Database Service (RDS) instances, can be associated with one or more security groups.

‍

Security groups operate at the instance level, meaning that they define rules that specify what traffic is allowed to reach the associated resources. These rules can be applied to both incoming and outgoing traffic, providing a granular way to manage access to your AWS resources.

How Do AWS Security Groups Work?

To comprehend how AWS Security Groups, in conjunction with AWS security tools, function within the AWS ecosystem, envision them as gatekeepers for inbound and outbound network traffic. These gatekeepers rely on a predefined set of rules to determine whether traffic is permitted or denied.

‍

Here's a simplified breakdown of the process:

Inbound Traffic: When an incoming packet arrives at an AWS resource, AWS evaluates the rules defined in the associated security group. If the packet matches any of the rules allowing the traffic, it is permitted; otherwise, it is denied.

Outbound Traffic: Outbound traffic from an AWS resource is also controlled by the security group's rules. It follows the same principle: traffic is allowed or denied based on the rules defined for outbound traffic.

Illustration of how security groups work in AWS.

Security groups are stateful, which means that if you allow inbound traffic from a specific IP address, the corresponding outbound response traffic is automatically allowed. This simplifies rule management and ensures that related traffic is not blocked.

Types of Security Groups in AWS

There are two types of AWS Security Groups:

‍

Types of AWS Security Groups Description
EC2-Classic Security Groups These are used with instances launched in the EC2-Classic network. It is an older network model, and AWS encourages the use of Virtual Private Cloud (VPC) for new instances.
VPC Security Groups These are used with instances launched within a Virtual Private Cloud (VPC). VPCs offer more advanced networking features and are the standard for creating isolated network environments in AWS.

‍

For this guide, we will focus on VPC Security Groups as they are more versatile and widely used.

How to Use Multiple Security Groups in AWS

In AWS, you can associate multiple security groups with a single resource. When multiple security groups are associated with an instance, AWS combines their rules. This is done in a way that allows for flexibility and ease of management. The rules are evaluated as follows:

‍

  • Union: Rules from different security groups are merged. If any security group allows the traffic, it is permitted.
  • Deny Overrides Allow: If a rule in one security group denies the traffic, it takes precedence over any rule that allows the traffic in another security group.
  • Default Deny: If a packet doesn't match any rule, it is denied by default.

‍

Let's explore how to create, manage, and configure security groups in AWS.

Security Groups and Network ACLs

Before diving into security group creation, it's essential to understand the difference between security groups and Network Access Control Lists (NACLs). While both are used to control inbound and outbound traffic, they operate at different levels.

‍

Security Groups: These operate at the instance level, filtering traffic to and from the resources (e.g., EC2 instances). They are stateful, which means that if you allow incoming traffic from a specific IP, outbound response traffic is automatically allowed.

‍

Network ACLs (NACLs): These operate at the subnet level and act as stateless traffic filters. NACLs define rules for all resources within a subnet, and they do not automatically allow response traffic.

Illustration of how security groups and Network ACLs work.

For the most granular control over traffic, use security groups for instance-level security and NACLs for subnet-level security.

AWS Security Groups Outbound Rules

AWS Security Groups are defined by a set of rules that specify which traffic is allowed and which is denied. Each rule consists of the following components:

‍

  • Type: The protocol type (e.g., TCP, UDP, ICMP) to which the rule applies.
  • Port Range: The range of ports to which the rule applies.
  • Source/Destination: The IP range or security group that is allowed to access the resource.
  • Allow/Deny: Whether the rule allows or denies traffic that matches the rule criteria.

‍

Now, let's look at how to create a security group in AWS.

Creating a Security Group in AWS

To create a security group in AWS (through the console), follow these steps:

Steps Description
Sign in to the AWS Management Console Log in to your AWS account.
Navigate to the EC2 Dashboard Select the "EC2" service.
Access the Security Groups Section In the EC2 Dashboard, under the "Network & Security" category, click on "Security Groups" in the navigation pane on the left.
Create a New Security Group Click the "Create Security Group" button.
Configure Security Group Settings
  • Security Group Name: Give your security group a descriptive name.
  • Description: Provide a brief description of the security group's purpose.
  • Add Inbound Rules: Under the "Inbound Rules" section, define rules for incoming traffic. Click the "Add Rule" button and specify the type, port range, and source IP or security group.
Add Outbound Rules Similarly, add rules for outbound traffic under the "Outbound Rules" section.
Review and Create Double-check your rule settings and click "Create Security Group."

‍

Your security group is now created and ready to be associated with AWS resources.

Below, we'll demonstrate how to create a security group using the AWS CLI.

 
aws ec2 create-security-group --group-name MySecurityGroup --description
"My Security Group"

In the above command:

--group-name specifies the name of your security group.

--description provides a brief description of the security group.

‍

After executing this command, AWS will return the security group's unique identifier, which is used to reference the security group in subsequent commands.

Adding a Rule to a Security Group

Once your security group is created, you can easily add, edit, or remove rules. To add a new rule to an existing security group through a console, follow these steps:

‍

  1. Select the security group you want to modify in the EC2 Dashboard.
  2. In the "Inbound Rules" or "Outbound Rules" tab, click the "Edit Inbound Rules" or "Edit Outbound Rules" button.
  3. Click the "Add Rule" button.
  4. Define the rule with the appropriate type, port range, and source/destination.
  5. Click "Save Rules."

‍

To create a Security Group, you can also use the create-security-group command, specifying a name and description. After creating the Security Group, you can add rules to it using the authorize-security-group-ingress and authorize-security-group-egress commands. The code snippet below adds an inbound rule to allow SSH traffic from a specific IP address range.

 
# Create a new Security Group
aws ec2 create-security-group --group-name MySecurityGroup --description "My Security Group"

# Add an inbound rule to allow SSH traffic from a specific IP address
aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 203.0.113.0/24

Assigning a Security Group to an EC2 Instance

To secure your EC2 instances using security groups through the console, follow these steps:

‍

  1. Navigate to the EC2 Dashboard in the AWS Management Console.
  2. Select the EC2 instance to which you want to assign a security group.
  3. Click the "Actions" button, choose "Networking," and then click "Change Security Groups."
  4. In the "Assign Security Groups" dialog, select the desired security group(s) and click "Save."

‍

Your EC2 instance is now associated with the selected security group(s), and its inbound and outbound traffic is governed by the rules defined in those groups.

 
# Launch an EC2 instance and associate it with a Security Group
aws ec2 run-instances --image-id ami-12345678 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-0123456789abcdef0

When launching an EC2 instance, you can specify the Security Groups to associate with it. In the example above, we associate the instance with a Security Group using the --security-group-ids flag.

Deleting a Security Group

To delete a security group via the AWS Management Console, follow these steps:

‍

  1. In the EC2 Dashboard, select the security group you wish to delete.
  2. Check for associated instances and disassociate them, if necessary.
  3. Click the "Actions" button, and choose "Delete Security Group."
  4. Confirm the deletion when prompted.
  5. Receive confirmation of the security group's removal.
 
# Delete a Security Group
aws ec2 delete-security-group --group-id sg-0123456789abcdef0

To delete a Security Group, you can use the delete-security-group command and specify the Security Group's ID through AWS CLI.

AWS Security Groups Best Practices

Here are some additional best practices to keep in mind when working with AWS Security Groups:

Enable Tracking and Alerting

One best practice is to enable tracking and alerting for changes made to your Security Groups. AWS provides a feature called AWS Config, which allows you to track changes to your AWS resources, including Security Groups. By setting up AWS Config, you can receive notifications when changes occur, helping you detect and respond to any unauthorized modifications quickly.

Delete Unused Security Groups

Over time, you may end up with unused or redundant Security Groups in your AWS environment. It's essential to regularly review your Security Groups and delete any that are no longer needed. This reduces the complexity of your security policies and minimizes the risk of accidental misconfigurations.

Avoid Incoming Traffic Through 0.0.0.0/0

One common mistake in Security Group configurations is allowing incoming traffic from '0.0.0.0/0,' which essentially opens up your resources to the entire internet. It's best to avoid this practice unless you have a specific use case that requires it. Instead, restrict incoming traffic to only the IP addresses or IP ranges necessary for your applications.

Use Descriptive Rule Names

When creating Security Group rules, provide descriptive names that make it clear why the rule exists. This simplifies rule management and auditing.

Implement Least Privilege

Follow the principle of least privilege by allowing only the minimum required access to your resources. Avoid overly permissive rules.

Regularly Review and Update Rules

Your security requirements may change over time. Regularly review and update your Security Group rules to adapt to evolving security needs.

Avoid Using Security Group Rules as the Only Layer of Defense

Security Groups are a crucial part of your defense, but they should not be your only layer of security. Combine them with other security measures, such as NACLs and web application firewalls, for a comprehensive security strategy.

Leverage AWS Identity and Access Management (IAM)

Use AWS IAM to control access to AWS services and resources. IAM roles and policies can provide fine-grained control over who can modify Security Groups and other AWS resources.

Implement Network Segmentation

Use different Security Groups for different tiers of your application, such as web servers, application servers, and databases. This helps in implementing network segmentation and ensuring that resources only communicate as necessary.

Regularly Audit and Monitor

Set up auditing and monitoring tools to detect and respond to security incidents promptly. AWS provides services like AWS CloudWatch and AWS CloudTrail for this purpose.

Conclusion

Securing your cloud environment is paramount when using AWS, and Security Groups play a vital role in achieving this goal. By understanding how Security Groups work, creating and managing rules, and following best practices, you can enhance the security of your AWS resources. Remember to regularly review and update your security group configurations to adapt to changing security requirements and maintain a robust defense against potential threats. With the right approach to AWS Security Groups, you can confidently embrace the benefits of cloud computing while ensuring the safety and integrity of your applications and data.

<blogcta-big>

‍

Author Image
Ron Reiter
Co-Founder and CTO
linkedin logotwitter logo

Discover Ron’s expertise, shaped by over 20 years of hands-on tech and leadership experience in cybersecurity, cloud, big data, and machine learning. As a serial entrepreneur and seed investor, Ron has contributed to the success of several startups, including Axonius, Firefly, Guardio, Talon Cyber Security, and Lightricks, after founding a company acquired by Oracle.

Subscribe

Latest Blog Posts

Dean Taler
Dean Taler
September 16, 2025
5
Min Read
Compliance

How to Write an Effective Data Security Policy

How to Write an Effective Data Security Policy

Introduction: Why Writing Good Policies Matters

In modern cloud and AI-driven environments, having security policies in place is no longer enough. The quality of those policies directly shapes your ability to prevent data exposure, reduce noise, and drive meaningful response. A well-written policy helps to enforce real control and provides clarity in how to act. A poorly written one, on the other hand, fuels alert fatigue, confusion, or worse - blind spots.

‍

This article explores how to write effective, low-noise, action-oriented security policies that align with how data is actually used.

What Is a Data Security Policy?

A data security policy is a set of rules that defines how your organization handles sensitive data. It specifies who can access what information, under what conditions, and what happens when those rules are violated. But here's the key difference: a good data security policy isn't just a document that sits in a compliance folder. It's an active control that detects risky behavior and triggers specific responses. While many organizations write policies that sound impressive but create endless alerts, effective policies target real risks and drive meaningful action. The goal isn't to monitor everything, it's to catch the activities that actually matter and respond quickly when they happen.

What Makes a Data Security Policy “Good”?

Before you begin drafting, ask yourself: what problem is this policy solving, and why does it matter? 

A good data security policy isn’t just a technical rule sitting in a console, it’s a sensor for meaningful risk. It should define what activity you want to detect, under what conditions it should trigger, and who or what is in scope, so that it avoids firing on safe, expected scenarios.

‍

Key characteristics of an effective policy:
‍

  • Clear intent: protects against a well-defined risk, not a vague category of threats.
  • Actionable outcome: leads to a specific, repeatable response.
  • Low noise: triggers only on unusual or risky patterns, not normal operations.
  • Context-aware: accounts for business processes and expected data use.

💡 Tip: If you can’t explain in one sentence what you want to detect and what action should happen when it triggers, your policy isn’t ready for production.

Turning Risk Into Actionable Policy

Data security policies should always be grounded in real business risk, not just what’s technically possible to monitor. A strong policy targets scenarios that could genuinely harm the organization if left unchecked.

‍

Questions to ask before creating a policy:
‍

  • What specific behavior poses a risk to our sensitive or regulated data?
  • Who might trigger it, and why? Is it more likely to be malicious, accidental, or operational?
  • What exceptions or edge cases should be allowed without generating noise?
  • What systems will enforce it and who owns the response when it fires?

Instead of vague statements like “No access to PII”, write with precision:

‍
“Block and alert on external sharing of customer PII from corporate cloud storage to any domain not on the approved partner list, unless pre-approved via the security exception process.”
‍

Recommendations:
‍

  • Treat policies like code - start them in monitor-only mode.
  • Test both sides: validate true positives (catching risky activity) and avoid false positives (triggering on normal behavior).

💡 Tip: The best policies are precise enough to detect real risks, but tested enough to avoid drowning teams in noise.

A Good Data Security Policy Should Drive Action

Policies are only valuable if they lead to a decision or action. Without a clear owner or remediation process, alerts quickly become noise. Every policy should generate an alert that leads to accountability.
‍

Questions to ask:
‍

  • Who owns the alert?
  • What should happen when it fires?
  • How quickly should it be resolved?

💡 Tip: If no one is responsible for acting on a policy’s alerts, it’s not a policy — it’s background noise.

Don’t Ignore the Noise

When too many alerts fire, it’s tempting to dismiss them as an annoyance. But noisy policies are often a signal, not a mistake. Sometimes policies are too broad or poorly scoped. Other times, they point to deeper systemic risks, such as overly open sharing practices or misconfigured controls.
‍

Recommendations:
‍

  • Investigate noisy policies before silencing them.
  • Treat excess alerts as a clue to systemic risk.

💡 Tip: A noisy policy may be exposing the exact weakness you most need to fix.

Know When to Adjust or Retire a Policy

Policies must evolve as your organization, tools, and data change. A rule that made sense last year might be irrelevant or counterproductive today.
‍

Recommendations:
‍

  • Continuously align policies with evolving risks.
  • Track key metrics: how often it triggers, severity, and response actions.
  • Optimize response paths so alerts reach the right owners quickly.
  • Schedule quarterly or biannual reviews with both security and business stakeholders.

💡 Tip: The only thing worse than no policy is a stale one that everyone ignores.

Why Smart Policies Matter for Regulated Data

Data security policies aren’t just an internal safeguard, they are how compliance is enforced in practice. Regulations like GDPR, HIPAA, and PCI DSS require demonstrable control over sensitive data.

Poorly written policies generate alert fatigue, making it harder to detect real violations. Well-crafted ones reduce the risk of noncompliance, streamline audits, and improve breach response.
‍

Recommendations:
‍

  • Map each policy directly to a specific regulatory requirement.
  • Retire rules that create noise without reducing actual risk.

💡 Tip: If a policy doesn’t map to a regulation or a real risk, it’s adding effort without adding value.

Making Policy Creation Simple, Powerful, and Built for Results 

An effective solution for policy creation should make it easy to get started, provide the flexibility to adapt to your unique environment, and give you the deep data context you need to make policies that actually work. It should streamline the process so you can move quickly without sacrificing control, compliance, or clarity.

‍

Sentra is that solution. By combining intuitive policy building with deep data context, Sentra simplifies and strengthens the entire lifecycle of policy creation.
‍

With Sentra, you can:
‍

  • Start fast with out-of-the-box, low-noise controls.
  • Create custom policies without complexity.
  • Leverage real-time knowledge of where sensitive data lives and who has access to it.
  • Continuously tune for low noise with performance metrics.
  • Understand which regulations you can adhere to
    ‍

💡 Tip: The true value of a policy isn’t how often it triggers, it’s whether it consistently drives the right response.

‍

Good Policies Start with Good Visibility

The best data security policies are written by teams who know exactly where sensitive data lives, how it moves, who can access it, and what creates risk. Without that visibility, policy writing becomes guesswork. With it, enforcement becomes simple, effective, and sustainable.
‍

At Sentra, we believe policy creation should be driven by real data, not assumptions. If you’re ready to move from reactive alerts to meaningful control.

<blogcta-big>

‍

Read More
Nikki Ralston
Nikki Ralston
Gilad Golani
Gilad Golani
September 3, 2025
5
Min Read
Data Loss Prevention

Supercharging DLP with Automatic Data Discovery & Classification of Sensitive Data

Supercharging DLP with Automatic Data Discovery & Classification of Sensitive Data

Data Loss Prevention (DLP) is a keystone of enterprise security, yet traditional DLP solutions continue to suffer from high rates of both false positives and false negatives, primarily because they struggle to accurately identify and classify sensitive data in cloud-first environments.

‍

New advanced data discovery and contextual classification technology directly addresses this gap, transforming DLP from an imprecise, reactive tool into a proactive, highly effective solution for preventing data loss.

Why DLP Solutions Can’t Work Alone

DLP solutions are designed to prevent sensitive or confidential data from leaving your organization, support regulatory compliance, and protect intellectual property and reputation. A noble goal indeed.  Yet DLP projects are notoriously anxiety-inducing for CISOs. On the one hand,  they often generate a high amount of false positives that disrupt legitimate business activities and further exacerbate alert fatigue for security teams.

‍

What’s worse than false positives? False negatives. Today traditional DLP solutions too often fail to prevent data loss because they cannot efficiently discover and classify sensitive data in dynamic, distributed, and ephemeral cloud environments.

‍

Traditional DLP faces a twofold challenge: 

  • High False Positives: DLP tools often flag benign or irrelevant data as sensitive, overwhelming security teams with unnecessary alerts and leading to alert fatigue.

  • High False Negatives: Sensitive data is frequently missed due to poor or outdated classification, leaving organizations exposed to regulatory, reputational, and operational risks.

These issues stem from DLP’s reliance on basic pattern-matching, static rules, and limited context. As a result, DLP cannot keep pace with the ways organizations use, store, and share data, resulting in the dual-edged sword of both high false positives and false negatives. Furthermore, the explosion of unstructured data types and shadow IT creates blind spots that traditional DLP solutions cannot detect. As a result, DLP often can’t  keep pace with the ways organizations use, store, and share data. It isn’t that DLP solutions don’t work, rather they lack the underlying discovery and classification of sensitive data needed to work correctly.

AI-Powered Data Discovery & Classification Layer

Continuous, accurate data classification is the foundation for data security. An AI-powered data discovery and classification platform can act as the intelligence layer that makes DLP work as intended. Here’s how Sentra complements the core limitations of DLP solutions:

1. Continuous, Automated Data Discovery

  • Comprehensive Coverage: Discovers sensitive data across all data types and locations - structured and unstructured sources, databases, file shares, code repositories, cloud storage, SaaS platforms, and more.

  • Cloud-Native & Agentless: Scans your entire cloud estate (AWS, Azure, GCP, Snowflake, etc.) without agents or data leaving your environment, ensuring privacy and scalability.
    ‍
  • Shadow Data Detection: Uncovers hidden or forgotten (“shadow”) data sets that legacy tools inevitably miss, providing a truly complete data inventory.

2. Contextual, Accurate Classification

  • AI-Driven Precision: Sentra proprietary LLMs and hybrid models achieve over 95% classification accuracy, drastically reducing both false positives and false negatives.

  • Contextual Awareness: Sentra goes beyond simple pattern-matching to truly understand business context, data lineage, sensitivity, and usage, ensuring only truly sensitive data is flagged for DLP action.
    ‍
  • Custom Classifiers: Enables organizations to tailor classification to their unique business needs, including proprietary identifiers and nuanced data types, for maximum relevance.

3. Real-Time, Actionable Insights

  • Sensitivity Tagging: Automatically tags and labels files with rich metadata, which can be fed directly into your DLP for more granular, context-aware policy enforcement.

  • API Integrations: Seamlessly integrates with existing DLP, IR, ITSM, IAM, and compliance tools, enhancing their effectiveness without disrupting existing workflows.
  • Continuous Monitoring: Provides ongoing visibility and risk assessment, so your DLP is always working with the latest, most accurate data map.

How Sentra Supercharges DLP Solutions

How Sentra supercharges DLP solutions

Better Classification Means Less Noise, More Protection

  • Reduce Alert Fatigue: Security teams focus on real threats, not chasing false alarms, which results in better resource allocation and faster response times.

  • Accelerate Remediation: Context-rich alerts enable faster, more effective incident response, minimizing the window of exposure.

  • Regulatory Compliance: Accurate classification supports GDPR, PCI DSS, CCPA, HIPAA, and more, reducing audit risk and ensuring ongoing compliance.

  • Protect IP and Reputation: Discover and secure proprietary data, customer information, and business-critical assets, safeguarding your organization’s most valuable resources.

Why Sentra Outperforms Legacy Approaches

Sentra’s hybrid classification framework combines rule-based systems for structured data with advanced LLMs and zero-shot learning for unstructured and novel data types.

‍

This versatility ensures:

‍

  • Scalability: Handles petabytes of data across hybrid and multi-cloud environments, adapting as your data landscape evolves.
  • Adaptability: Learns and evolves with your business, automatically updating classifications as data and usage patterns change.
  • Privacy: All scanning occurs within your environment - no data ever leaves your control, ensuring compliance with even the strictest data residency requirements.

Use Case: Where DLP Alone Fails, Sentra Prevails

A financial services company uses a leading DLP solution to monitor and prevent the unauthorized sharing of sensitive client information, such as account numbers and tax IDs, across cloud storage and email. The DLP is configured with pattern-matching rules and regular expressions for identifying sensitive data.

‍

What Goes Wrong:

‍
An employee uploads a spreadsheet to a shared cloud folder. The spreadsheet contains a mix of client names, account numbers, and internal project notes. However, the account numbers are stored in a non-standard format (e.g., with dashes, spaces, or embedded within other text), and the file is labeled with a generic name like “Q2_Projects.xlsx.” The DLP solution, relying on static patterns and file names, fails to recognize the sensitive data and allows the file to be shared externally. The incident goes undetected until a client reports a data breach.

‍

How Sentra Solves the Problem:

‍
To address this, the security team set out to find a solution capable of discovering and classifying unstructured data without creating more overhead. They selected Sentra for its autonomous ability to continuously discover and classify all types of data across their hybrid cloud environment. Once deployed, Sentra immediately recognizes the context and content of files like the spreadsheet that enabled the data leak. It accurately identifies the embedded account numbers—even in non-standard formats—and tags the file as highly sensitive.

‍

This sensitivity tag is automatically fed into the DLP, which then successfully enforces strict sharing controls and alerts the security team before any external sharing can occur. As a result, all sensitive data is correctly classified and protected, the rate of false negatives was dramatically reduced, and the organization avoids further compliance violations and reputational harm.

Getting Started with Sentra is Easy

  1. Deploy Agentlessly: No complex installation. Sentra integrates quickly and securely into your environment, minimizing disruption.

  2. Automate Discovery & Classification: Build a living, accurate inventory of your sensitive data assets, continuously updated as your data landscape changes.

  3. Enhance DLP Policies: Feed precise, context-rich sensitivity tags into your DLP for smarter, more effective enforcement across all channels.

  4. Monitor Continuously: Stay ahead of new risks with ongoing discovery, classification, and risk assessment, ensuring your data is always protected.

“Sentra’s contextual classification engine turns DLP from a reactive compliance checkbox into a proactive, business-enabling security platform.”

‍

Fuel DLP with Automatic Discovery & Classification

DLP is an essential data protection tool, but without accurate, context-aware data discovery and classification, it’s incomplete and often ineffective. Sentra supercharges your DLP with continuous data discovery and accurate classification, ensuring you find and protect what matters most—while eliminating noise, inefficiency, and risk. 

‍

Ready to see how Sentra can supercharge your DLP? Contact us for a demo today.

<blogcta-big>

‍

Read More
Veronica Marinov
Veronica Marinov
Romi Minin
Romi Minin
May 15, 2025
5
Min Read
AI and ML

Ghosts in the Model: Uncovering Generative AI Risks

Ghosts in the Model: Uncovering Generative AI Risks

Generative AI risks are no longer hypothetical. They’re shaping the way enterprises think about cloud security. As artificial intelligence (AI) becomes deeply integrated into enterprise workflows, organizations are increasingly leveraging cloud-based AI services to enhance efficiency and decision-making.

‍

In 2024, 56% of organizations adopted AI to develop custom applications, with 39% of Azure users leveraging Azure OpenAI services. However, with rapid AI adoption in cloud environments, security risks are escalating. As AI continues to shape business operations, the security and privacy risks associated with cloud-based AI services must not be overlooked. Understanding these risks (and how to mitigate them) is essential for organizations looking to protect their proprietary models and sensitive data.

‍Types of Generative AI Risks in Cloud Environments

When discussing AI services in cloud environments, there are two primary types of services that introduce different types of security and privacy risks. This article dives into these risks and explores best practices to mitigate them, ensuring organizations can leverage AI securely and effectively.

1. Data Exposure and Access Risks in Generative AI Platforms

Examples include OpenAI, Google, Meta, and Microsoft, which develop large-scale AI models and provide AI-related services, such as Azure OpenAI, Amazon Bedrock, Google’s Bard, Microsoft Copilot Studio. These services allow organizations to build AI Agents and GenAI services that  are designed to help users perform tasks more efficiently by integrating with existing tools and platforms. For instance, Microsoft Copilot can provide writing suggestions, summarize documents, or offer insights within platforms like Word or Excel, though securing regulated data in Microsoft 365 Copilot requires specific security considerations..

What is RAG (Retrieval-Augmented Generation)?

Many AI systems use Retrieval-Augmented Generation (RAG) to improve accuracy. Instead of solely relying on a model’s pre-trained knowledge, RAG allows the system to fetch relevant data from external sources, such as a vector database, using algorithms like k-nearest neighbor. This retrieved information is then incorporated into the model’s response.

‍

When used in enterprise AI applications, RAG enables AI agents to provide contextually relevant responses. However, it also introduces a risk - if access controls are too broad, users may inadvertently gain access to sensitive corporate data.

How Does RAG (Retrieval-Augmented Generation) Apply to AI Agents?

In AI agents, RAG is typically used to enhance responses by retrieving relevant information from a predefined knowledge base.

‍

Example: In AWS Bedrock, you can define a serverless vector database in OpenSearch as a knowledge base for a custom AI agent. This setup allows the agent to retrieve and incorporate relevant context dynamically, effectively implementing RAG.

Generative AI Risks and Security Threats of AI Platforms

Custom generative AI applications, such as AI agents or enterprise-built copilots, are often integrated with organizational knowledge bases like Amazon S3, SharePoint, Google Drive, and other data sources. While these models are typically not directly trained on sensitive corporate data, the fact that they can access these sources creates significant security risks.

One potential generative AI risk is data exposure through prompts, but this only arises under certain conditions. If access controls aren’t properly configured, users interacting with AI agents might unintentionally or maliciously - prompt the model to retrieve confidential or private information.This isn’t limited to cleverly crafted prompts; it reflects a broader issue of improper access control and governance.

Configuration and Access Control Risks

The configuration of the AI agent is a critical factor. If an agent is granted overly broad access to enterprise data without proper role-based restrictions, it can return sensitive information to users who lack the necessary permissions. For instance, a model connected to an S3 bucket with sensitive customer data could expose that data if permissions aren’t tightly controlled. Simple misconfigurations can lead to serious data exposure incidents, even in applications designed for security.

‍

A common scenario might involve an AI agent designed for Sales that has access to personally identifiable information (PII) or customer records. If the agent is not properly restricted, it could be queried by employees outside of Sales, such as developers - who should not have access to that data.

Example Generative AI Risk Scenario

An employee asks a Copilot-like agent to summarize company-wide sales data. The AI returns not just high-level figures, but also sensitive customer or financial details that were unintentionally exposed due to lax access controls.

Challenges in Mitigating Generative AI Risks

The core challenge, particularly relevant to platforms like Sentra, is enforcing governance to ensure only appropriate data is used and accessible by AI services.

‍

This includes:

  • Defining and enforcing granular data access controls.
  • Preventing misconfigurations or overly permissive settings.
  • Maintaining real-time visibility into which data sources are connected to AI models.
  • Continuously auditing data flows and access patterns to prevent leaks.

Without rigorous governance and monitoring, even well-intentioned GenAI implementations can lead to serious data security incidents.

2. ML and AI Studios for Building New Models

Many companies, such as large financial institutions, build their own AI and ML models to make better business decisions, or to improve their user experiences. Unlike large foundational models from major tech companies, these custom AI models are trained by the organization itself on their applications or corporate data.
‍

Security Risks of Custom AI Models

  1. Weak Data Governance Policies - If data governance policies are inadequate, sensitive information, such as customers' Personally Identifiable Information (PII), could be improperly accessed or shared during the training process. This can lead to data breaches, privacy compliance violations, and unethical AI usage. The growing recognition of generative AI-related risks has driven the development of more AI compliance frameworks that are now being actively enforced with significant penalties..
    ‍
  2. Excessive Access to Training Data and AI Models - Granting unrestricted access to training datasets and machine learning (ML)/AI models increases the risk of data leaks and misuse. Without proper access controls, sensitive data used in training can be exposed to unauthorized individuals, leading to compliance and security concerns.
    ‍
  3. AI Agents Exposing Sensitive Data -  AI agents that do not have proper safeguards can inadvertently expose sensitive information to a broad audience within an organization. For example, an employee could retrieve confidential data such as the CEO’s salary or employment contracts if access controls are not properly enforced.
    ‍
  4. Insecure Model Storage – Once a model is trained, it is typically stored in the same environment (e.g., in Amazon SageMaker, the training job stores the trained model in S3). If not properly secured, proprietary models could be exposed to unauthorized access, leading to risks such as model theft.
    ‍
  5. Deployment Vulnerabilities – A lack of proper access controls can result in unauthorized use of AI models. Organizations need to assess who has access: Is the model public? Can external entities interact with or exploit it?

Shadow AI and Forgotten Assets – AI models or artifacts that are not actively monitored or properly decommissioned can become a security risk. These overlooked assets can serve as attack vectors if discovered by malicious actors.

Example Risk Scenario

A bank develops an AI-powered feature that predicts a customer’s likelihood of repaying a loan based on inputs like financial history, employment status, and other behavioral indicators. While this feature is designed to enhance decision-making and customer experience, it introduces significant generative AI risk if not properly governed.
‍

During development and training, the model may be exposed to personally identifiable information (PII), such as names, addresses, social security numbers, or account details, which is not necessary for the model’s predictive purpose.
‍

⚠️ Best practice: Models should be trained only on the minimum necessary data required for performance, excluding direct identifiers unless absolutely essential. This reduces both privacy risk and regulatory exposure.

If the training pipeline fails to properly separate or mask this PII, the model could unintentionally leak sensitive information. For example, when responding to an end-user query, the AI might reference or infer details from another individual’s record - disclosing sensitive customer data without authorization.

‍

This kind of data leakage, caused by poor data handling or weak governance during training, can lead to serious regulatory non-compliance, including violations of GDPR, CCPA, or other privacy frameworks.

Common Risk Mitigation Strategies and Their Limitations

Many organizations attempt to manage generative AI-related risks through employee training and awareness programs. Employees are taught best practices for handling sensitive data and using AI tools responsibly.
While valuable, this approach has clear limitations:
‍

  • Training Alone Is Insufficient:
     Human error remains a major risk factor, even with proper training. Employees may unintentionally connect sensitive data sources to AI models or misuse AI-generated outputs.

  • Lack of Automated Oversight:
     Most organizations lack robust, automated systems to continuously monitor how AI models use data and to enforce real-time security policies. Manual review processes are often too slow and incomplete to catch complex data access risks in dynamic, cloud-based AI environments.
    ‍
  • ‍Policy Gaps and Visibility Challenges:
    Organizations often operate with multiple overlapping data layers and services. Without clear, enforceable policies, especially automated ones - certain data assets may remain unscanned or unprotected, creating blind spots and increasing risk.

Reducing AI Risks with Sentra’s Comprehensive Data Security Platform

Managing generative AI risks in the cloud requires more than employee training.
Organizations need to adopt robust data governance frameworks and data security platforms (like Sentra’s) that address the unique challenges of AI.

This includes:

  • Discovering AI Assets: Automatically identify AI agents, knowledge bases, datasets, and models across the environment.
  • Classifying Sensitive Data: Use automated classification and tagging to detect and label sensitive information accurately.
    Monitoring AI Data Access: Detect which AI agents and models are accessing sensitive data, or using it for training - in real time.
  • Enforcing Access Governance: Govern AI integrations with knowledge bases by role, data sensitivity, location, and usage to ensure only authorized users can access training data, models, and artifacts.
  • Automating Data Protection: Apply masking, encryption, access controls, and other protection methods through automated remediation capabilities across data and AI artifacts used in training and inference processes.

By combining strong technical controls with ongoing employee training, organizations can significantly reduce the risks associated with AI services and ensure compliance with evolving data privacy regulations.

<blogcta-big>

‍

Read More
decorative ball
Expert Data Security Insights Straight to Your Inbox
What Should I Do Now:
1

Get the latest GigaOm DSPM Radar report - see why Sentra was named a Leader and Fast Mover in data security.Download now and stay ahead on securing sensitive data.

2

Sign up for a demo and learn how Sentra’s data security platform can uncover hidden risks, simplify compliance, and safeguard your sensitive data.

3

Follow us on LinkedIn, X (Twitter), and YouTube for actionable expert insights on how to strengthen your data security, build a successful DSPM program, and more!