Fed Ramp Cloud Authorizations, AWS Ingestion Scenarios & Connector Architecture
Clouds and FEDRAMP
Before we dive into how to ingest data from AWS into Microsoft Sentinel, we need to understand what levels each cloud is FedRamp authorized to operate. This is not a deep discussion on compliance, just a quick overview of what levels each cloud is authorized to operate at. For specific compliance or operating level guidance you are encouraged to talk to your agencies authorized approver.
Microsoft, Amazon, and Google provide multiple cloud services designed specifically to support US government consumers and the commercial businesses that support these agencies. These services are broken down across Azure, Office 365, AWS, and the GCP Clouds.
Please note, this information is current as of April 2024. For the most up-to-date status, refer to the links below.
Microsoft Clouds
- Azure
- Microsoft Azure Commercial (MAC) – FedRamp High, DISA IL2
- Microsoft Azure Government (MAG) – FedRamp High, DISA IL4, DISA IL5
- Office 365 and the Microsoft Defender XDR security suite
- Government Community Cloud Moderate (GCC) – FedRamp Mod, DISA IL2
- Government Community Cloud High (GCCH) – FedRamp High, DISA IL4
- Office 365 DoD – DISA IL5
Amazon Web Services Clouds
- AWS – FedRamp Moderate
- AWS GovCloud – FedRamp High
Google Cloud
- Google Cloud Platform – FedRamp High
Here is a list of direct links for the FedRamp authorizations from the FedRAMP Marketplace -
- Azure Government - https://marketplace.fedramp.gov/products/F1603087869
- Azure - https://marketplace.fedramp.gov/products/F1209051525
- Office GCC - Microsoft Office 365 GCC High | FedRAMP Marketplace
- Office GCCH - Microsoft Office 365 GCC High | FedRAMP Marketplace
- AWS GovCloud - https://marketplace.fedramp.gov/products/F1603047866
- AWS - https://marketplace.fedramp.gov/products/AGENCYAMAZONEW
- GCP - Google Services | FedRAMP Marketplace
To understand the Microsoft Sentinel architecture options, we need to first understand the relationship between the Azure Commercial and Government clouds. This will help determine where Sentinel and the underlying Log Analytics Workspace will reside, and which version of Sentinel will be used to ingest both Microsoft and non-Microsoft security data. For example,
- The Log Analytics Workspace for data ingested from Office 365 Commercial and Office 365 GCC is in Azure Commercial.
- The Log Analytics Workspace for data ingested from Office 365 GCCH and Office 365 DOD is in Azure Government.
Log storage locations for Microsoft Clouds
Amazon Web Services (AWS) data ingestion into Sentinel scenarios
Microsoft understands that many customers may have multiple AWS accounts in both commercial and government clouds. Here are the scenarios for getting data from AWS versions into Sentinel -
- AWS Gov -> Microsoft Sentinel, Azure Government
- AWS Gov -> Microsoft Sentinel, Azure Commercial
- AWS Com -> Microsoft Sentinel, Azure Government
- AWS Com -> Microsoft Sentinel, Azure Commercial
Architecture for the AWS connector
AWS Connector Architecture
In this architecture,
- AWS services are configured to send their logs to S3 (Simple Storage Service) storage bucket.
- The S3 bucket sends notification messages to the SQS (Simple Queue Service) message queues when it receives new logs. There is a unique SQS queue for each service.
SQS Queues for AWS services
- The Microsoft Sentinel AWS S3 connector polls the SQS queues at regular, frequent intervals. If there is a message in the queue, it will contain the path to the log files.
- The connector reads the message with the path, then fetches the files from the S3 bucket.
- To connect to the SQS queue and the S3 bucket, Microsoft Sentinel uses a federated web identity provider (Microsoft Entra ID) for authenticating with AWS through OpenID Connect (OIDC), and assuming an AWS IAM role. The role is configured with a permissions policy giving it access to those resources.
Summary
We reviewed the relationship between commercial and government cloud solutions as well as the compliance and architecture aspects of ingesting security data from non-Microsoft clouds into Sentinel. This solution allows customers to bring both Microsoft and non-Microsoft cloud security data into a single modern SOC environment while remaining compliant with government requirements and regulations. We did a high-level architectural review of the AWS Connector. In the next blog in this series, we will walk through the process of connecting AWS and AWS GovCloud to Microsoft Sentinel in Azure Government.