Customized AWS SCPs to support CloudGuard ingest

[crescentwire]

Hi everyone,

We recently signed on with Check Point's Infinity Platform, with particular interest in CloudGuard Posture Management. We have 12+ AWS accounts ranging from PoC to full-on Production and want to keep close tabs on what user activity and configured services look like over time. We have defined CloudTrail instances within each account, along with the required policies, roles, and S3 buckets.

However, because we're using Control Tower (with Organizations), we have a single AWS account with aggregated CloudTrail logs present in a single location. We've onboarded all our accounts referencing this single CloudTrail source but have run into problems with the applied AWS SCPs at the OU levels. Because Control Tower restricts access into any account it has ownership of, all externally sourced requests to pull logs and read AWS services are denied. After a few weeks of working with TAC, we determined we could manually change a single line in the applied SCPs in Control Tower. This worked perfectly... until Control Tower began complaining that our configuration was in a "drift state," blocking us from adding any new AWS accounts.

A colleague went ahead with re-deploying the AWS-generated SCPs across Control Tower and, as a result, our CloudGuard access is gone. The only fix I see is it reapply the one-off workaround with modifying the SCPs, but we will be right back in the same position then. ("Working," but "broken" from AWS' perspective.)

So, my question is this, please: those of you who use CloudGuard with Control Tower-integrated AWS environments... how do you do it? How do you apply permissions that allow ControlTower to retain ultimate authority, but with CloudGuard granted the access it needs to ingest and analyze data?

I appreciate any feedback or help you can provide. Please also let me know if you need more info or details on a particular area. 

Thanks very much for your time and help in advance.

[crescentwire]

Just to follow up, the root cause here was a specific AWS GuardRail blocking access to regions except for the ones we used (us-east-1 and us-west-2). The effect this produced in CloudGuard was an alert state next to each onboarded account's entry. TAC confirmed that CloudTrail events (and other details) were still being ingested properly, despite the visual warning we saw.

CloudGuard doesn't support excluding certain regions from being monitored by design; you'd want to know if someone deployed a resource or service in a region you didn't want them working in, especially if that would trigger unexpected costs within that billing period.

The "correct" approach here is to leave Control Tower's SCPs alone, living with an active alert state in CloudGuard. This isn't ideal, but it's the only option we (as a single customer) have at this time. Maybe someone else has figured a way around it, but for us, this makes the most sense.

(Just to reiterate, the reason the change to the SCP resolved these alerts is because it permitted CloudGuard to reach any of the AWS regions--not just the ones we were permitting with our single GuardRail. But those alerts clearing gave us a false impression that things weren't working before, even though they were. That's probably the most important takeaway from this.)

Hopefully this helps someone out there.