- 新しい順
- 投票が多い順
- コメントが多い順
The consoles are all https://<region>.console.aws.amazon.com/ with a generic of https://console.aws.amazon.com/, which will redirect you to a region once you have selected one, or default to us-east-1.
Thanks, Rodney, but the problem is that there's a huge number of other sites behind the scenes, reached by browser to retrieve JS, CSS files, images, to send API calls to. The partial list includes:
https://<some-random-value>.cloudfront.net https://a.b.cdn.console.awsstatic.com https://cdn.assets.as2.amazonaws.com https://<region>.signin.aws.amazon.com (for some reason, sites for more than single region are accessed) https://portal.sso.<region>.amazonaws.com https://global.ccs.amazonaws.com https://global.console.aws.amazon.com https://global.help-panel.docs.aws.a2z.com https://phd.aws.amazon.com https://portal.sso.<region>.amazonaws.com https://prod.log.shortbread.analytics.console.aws.a2z.com https://prod.tools.shortbread.analytics.console.aws.a2z.com https://static.global.sso.amazonaws.com https://website.sso-portal.<region>.amazonaws.com
And so on.
It's hard to compile a complete list by tracking browser calls. I could whitelist whole domains like aws.amazon.com or amazonaws.com, but I want to avoid opening access to services of tenants hosted on AWS - as opposed to native services of AWS itself. For instance, if I whitelist cloudfront.net, I'll allow access to anyone's site behind CloudFront.
Is there some way to distinguish between these two kinds of services?
As you surmise, there is no unique IP range because CloudFront supports all tenants, and the console apps (it is not one application) are running in the overall EC2 IP range and are implemented using AWS Services. What is the particular concern? I've see the desire to only allow their people to access their account's services, so we suggest using an Identity provider with Multi-factor authentication, SAML federation, and IAM Roles, and well-defined IAM access (you can use source IP, i.e. your NAT from your corporate network as a condition) to regulate access. Note that the NAT restriction prevents support personnel from accessing remotely unless they connect to your corporate VPN.
What is the particular concern?
We want stations on our network to reach only necessary sites, to avoid data exfiltration or stations' infection by malware. The same concerns that made Microsoft publish these instructions for Azure - https://learn.microsoft.com/en-us/azure/azure-portal/azure-portal-safelist-urls. I'm surprised a bit that Amazon didn't do it.
Allowing users to sign into particular AWS accounts only is another issue. By the way, how can it be implemented? In Azure, this is called "tenant restriction" and is implemented by injecting an HTTP header "Restrict-Access-To-Tenants: <permitted tenant list>" into calls to their login service.: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/tenant-restrictions
Does AWS have something like this?
You can use source IP to restrict access to the AWS services and console. See https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html. Typically this is the corporate NAT range. AWS console access is restricted through IAM. It is worth talking with your AWS account team to ask for this feature.
I'm NOT trying to limit who can sign into our AWS account. I'm trying to limit stations on a network behind my firewall, so that:
- their users would be able to sign into our AWS account via Management Console;
- their users WOULDN'T be able to sign into OTHER AWS accounts;
- the stations WOULDN'T be able to communicate with resources of other AWS tenants - say, their S3 endpoints or VM instances.
This is all realizable in Azure. Can this be implemented with AWS?
I have exactly the same question but haven't been able to find an answer yet. The issue is inconsistent access to the AWS console through our corporate proxy. There needs to be a whitelist of all possible top level domains. aws.amazon.com and amazonaws.com don't cover it.