When you ran inference on AWS Bedrock, the deal was explicit: prompts and completions stayed inside the AWS boundary, and model providers never saw your data. That guarantee is why regulated shops and European organizations route their AI workloads through Bedrock instead of going straight to the model vendor.
When you ran inference on AWS Bedrock, the deal was explicit: prompts and completions stayed inside the AWS boundary, and model providers never saw your data. That guarantee is why regulated shops and European organizations route their AI workloads through Bedrock instead of going straight to the model vendor.
I’ve spoken a lot about Security Invariants, but all of them have been implemented using Organizational Policies. That’s great, but organizational policies don’t apply to the Organizational Management Account (aka “payer”). So how does one implement invariants in a payer account?
AWS would tell you that you shouldn’t be giving anyone access to the payer account, so the need for invariants should be minimal. However, that doesn’t reflect the reality that AWS never protected its customers from themselves and prevented the enabling of Organizations or Control Tower in an account with existing workloads. I would say this is a failure of Customer Obsession and demonstrates Security is not the Top Priority. AWS would hide behind shared responsibility and blame the customer.
Regardless, there are many cases where workloads are in a payer account, and as a security person, you need to live with those workloads while protecting the rest of the AWS Organization. So, how do we build invariants into a payer account when SCPs and RCPs don’t apply?
Enter Permission Boundaries.
Most organizations have a preferred cloud provider. This is the provider where they have the most engineering expertise, have negotiated the best discounts, and have built the paved road experience.
tl;dr - here is a link to the scripts
In a typical ransomware attack, a threat actor will attempt to encrypt files on critical machines belonging to the victim. In exchange for a cryptocurrency payment, the threat actor will provide the decryption key and software to the victim, who then has to go through the arduous process of restoring their machines. The encrypted data is typically lost forever if the victim refuses to pay the ransom.
This is a revised version of the original post Leveraging AWS SSO (aka Identity Center) with Google Workspaces based on the new announcement AWS IAM Identity Center now supports automated user provisioning from Google Workspace The original post is still valid, and in someways may be better, but this version has it’s own advantages.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn’t clearly documented, and the provisioning support isn’t integrated, so here is a post to help you set it all up.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn’t clearly documented, and the provisioning support isn’t integrated, so here is a post to help you set it all up.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On) henceforth called AWS SSO (because AWS charges for egress), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
At BSides Atlanta today I gave a talk on how to handle an incident in AWS. The talk and this post is intended to help those already familiar with the principles of Incident Response to understand what to do when the incident involves the AWS Control Plane. You can find the Slides here.