I would like to restrict access to objects stored in an Amazon S3 bucket.
I would like to allow all the users on our LAN (they may or may not have amazon credentials since the entire infrastructure is not on AWS). I have seen some discussion around IP address filtering and VPC endpoint. Can someone please help me here? I am not sure if I can use VPC endpoint since all users on our lan are not in Amazon VPC.
Is this possible?
Thanks
Most likely your corporate LAN uses static IP addresses. You can create S3 policies to allow access (or deny) based upon IP addresses. Here is a good AWS article on this:
Restricting Access to Specific IP Addresses
VPC Endpoints are for VPC to AWS Services connectivity (basically using Amazon's private Internet instead of the public Internet. VPC Endpoints won't help you with Corporate connectivity (except if you are using Direct Connect).
Here is how I would solve it,
Configure
Configure Users from a corporate directory who use identity federation with SAML.
Create Groups
Apply Policies to Group
This will give fine-grained control and less maintenance overhead.
This will help you not only to control S3 but any future workloads you migrate to AWS and permissions to those resources as well.
IP based filtering are prone to security risk and with high maintenance in the long run and not scalable.
EDIT:
Adding more documentation to do the above,
Integrating ADFS with AWS IAM:
https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/
IAM Groups:
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html
Related
I work for the platform team of my company and we have a central AWS Network Firewall in a central VPC. We provide AWS accounts for different teams and if they need internet access, we connect the VPCs of the teams with a transit gateway to our central VPC and route traffic through our central VPC and firewall into the internet.
We currently only allow to reach certain domains that we whitelist. The problem is, that if we whitelist a URL, every AWS account can reach this URL. Sometimes an aws account needs to reach just one endpoint and not every endpoint, that is whitelisted.
My question is, is it possible to use some kind of conditional rules that only apply to certain accounts/VPCs?
We use Cloudformation for IaC. Any help and examples are highly appreciated!
Cheers
I'm working with AWS and need some support please.
My team provisioned Direct Connect and we can now enjoy private connectivity from our corporate network to VPC on AWS.
Management is asking if it's possible that aws cli commands are executed through Direct Connect and not through the public internet. Indeed, we have a lot of scripts with a lot of commands like aws ec2 describe-instances and so on. I guess these calls the public REST API of EC2 service that AWS exposes.
They're asking if it's possible that these calls do not go through the public internet.
I've seen VPC endpoints? Are they the solution?
See How can I access my Amazon S3 bucket over Direct Connect? for how to do this with S3.
Basically:
After BGP is up and established, the Direct Connect router advertises all global public IP prefixes, including Amazon S3 prefixes. Traffic heading to Amazon S3 is routed through the Direct Connect public virtual interface. The public virtual interface is routed through a private network connection between AWS and your data center or corporate network.
You can extend this to other Amazon services, per the AWS Direct Connect FAQs:
All AWS services, including Amazon Elastic Compute Cloud (EC2), Amazon Virtual Private Cloud (VPC), Amazon Simple Storage Service (S3), and Amazon DynamoDB can be used with Direct Connect.
Refer to #jarmod's answer below for the answer to the question but read on for why I think this sounds like an XY problem.
There is no reason at all why management should be concerned.
Third-party auditors assess the security and compliance of AWS services as part of multiple AWS compliance programs. Using the AWS CLI to access a service does not alter that service's compliance - AWS has compliance programs which pretty much cover every IT compliance framework out there globally.
Compliance aside, the AWS CLI does not store any customer data (there should be no data protection concerns) & transmits data securely (unless you manually override this).
The user guide highlights this:
The AWS CLI does not itself store any customer data other than the credentials it needs to interact with the AWS services on the user's behalf.
By default, all data transmitted from the client computer running the AWS CLI and AWS service endpoints is encrypted by sending everything through a HTTPS/TLS connection.
You don't need to do anything to enable the use of HTTPS/TLS. It is always enabled unless you explicitly disable it for an individual command by using the --no-verify-ssl command line option.
As if that's not enough, you can also add increased security when communicating with AWS services by enforcing a minimum version of TLS 1.2 to be used by the CLI.
There should be targeting of much much bigger attack vectors, like:
The physical accessibility of the device storing the credentials
Permanent access tokens vs. temporary credentials
IAM policies associated with the credentials
The AWS CLI is secure.
I have an Apache server running on an EC2 instance, from which I am serving a PHP webpage that lists EC2 instances under my account, allows for toggling them on/off, etc.
The problem is that the AWS SDK call (specifically describeInstances, but in general) can't reach the endpoint. I have looked into what IP ranges AWS uses, described here. I would like to avoid putting all of those IP ranges into my security group if possible. Because the endpoint resolves to different IPs in different requests, there doesn't seem to be one IP range that will work (besides 0.0.0.0/0, which I don't want to use).
Is there a way to allow outbound access to specifically AWS-provided services without manually entering all of these IP ranges? It seems like there should be a better way to do this.
I have hosted few services on AWS however all are public and can be accessed from anywhere which is a security threat, could you please let me know how to keep the services specific to internal users of organization without any authentication medium.
I found a workaround for this, if you have list of IP range may be a network administrator can help you, take that and put them in load balancers under security group.
You should spend some time reviewing security recommendations on AWS. Some excellent sources are:
Whitepaper: AWS Security Best Practices
AWS re:Invent 2017: Best Practices for Managing Security Operations on AWS (SID206) - YouTube
AWS re:Invent 2017: Security Anti-Patterns: Mistakes to Avoid (FSV301) - YouTube
AWS operates under a [Shared Responsibility Model, which means that AWS provides many security tools and capabilities, but it is your responsibility to use them correctly!
Basic things you should understand are:
Put public-facing resources in a Public Subnet. Everything else should go into a Private Subnet.
Configure Security Groups to only open a minimum number of ports and IP ranges to the Internet.
If you only want to open resources to "internal users of organization without any authentication medium", then you should connect your organization's network to AWS via AWS Direct Connect (private fiber connection) or via an encrypted VPN connection.
Security should be your first consideration in everything you put in the cloud — and, to be honest, everything you put in your own data center, too.
Consider a LEAST PRIVILEGE approach when planning Network VPC Architecture, NACL and Firewall rules as well as IAM Access & S3 Buckets.
LEAST PRIVILEGE: Configure the minimum permission and Access required in IAM,Bucket Policies, VPC Subnets, Network ACL and Security Groups with a need to know White-list approach.
Start from having specific VPCs with 2 Main Segments of Networks 1-Public and the other 2-Private.
You will place your DMZ components on the Public segment,
Components such as Internet Facing Web Server, load Balancers,
Gateways, etc falls here.
For the Rest such as Applications, Data, or Internal Facing
LoadBalancers or WebServers make sure you place them in the Private
Subnet where you will use an Internal IP address from specified
Internal Range to refer to the Components Inside the VPC.
If you have Multiple VPCs and you want them to talk with each
other you can Peer them together.
You also can use Route53 Internal DNS to simplify naming.
Just in case, If you need to have Internet access from the Private segment
you can Configure a NAT Gateway on the public subnet and handle
Outgoing Traffic routed to Internet from the NAT Gateway.
S3 Buckets can be Configured and Servered as VPC-END points. (Routing via an Internal Network rather than Internet Routed to S3 Buckets/Object).
In IAM you can create Policies to whitelist source IP and attached to Roles and Users which is a great combination to Mix Network VPN Connections/white-listed IPs and keep Network Access in harmony with IAM. That means even Console Access could be governed by a White-listed Policy.
I able to find that in my research there are some of the ways to find all our aws resources but will you suggest any solution to find public resources in aws our account.
Unfortunately, there is no easy way that you can find all resources that are allowed to communicate with outside world. However, the only way for most of the resources in AWS can connect to the internet through a VPC that is configured to allow access to 0.0.0.0/0 network with Security Group and ACL. So what you can do is to search for VPC ID on resources categories and if any results you get can connect to the internet.
This can be a very tedious task and this is NOT 100% guaranteed to find all resources as some resources has self-sustained VPC per resource such as S3. So my suggestion is you get used to using tags for resources.
Also maybe think about using infrastructure as code approach using something like Terraform.
If you have all of your instances in a VPC you could enable VPC Flow Logs on your VPC and then monitor all VPC traffic that way.
For the instances that are not in VPC's you could have CloudWatch logs enabled for that instance and then monitor the traffic that way.
Your instances should have security groups attached to them so that you could monitor the rules, and see if you have an OutBound Set to 0.0.0.0/0
You can give Netflix's Security Monkey a try. The tool will make a complete report of all secure and insecure AWS assets including Security Groups, IAM Policies and S3 Buckets. In fact, it also provides a ticketing like system to collab on such problems.
You can use IAM Access Analyzer console