I would like to know how to access only a specific AWS account (Ex A# 111111111111) using squid proxy.

Based on your situation, it seems like you want to restrict access to only certain AWS accounts through your Squid Proxy. While Squid can control access to certain IPs or domains, it doesn't have the ability to control access at an AWS account level. That kind of access control is typically done on the AWS side, using IAM roles and policies.

However, one approach you could take is to set up an AWS PrivateLink to a VPC endpoint service in your account. The AWS PrivateLink can be accessed from your corporate network and can be used to access only the services and AWS accounts you specify. You would need to set this up within your AWS account.

Note that this approach requires that the appropriate routing and security groups are set up in your AWS account and that the appropriate NAT rules are in place in your corporate network.

Here's a broad step outline for you:

• Create a VPC and VPC endpoint in AWS: This VPC will provide the network for your AWS resources. The VPC endpoint provides access to the AWS service.
• Create a Network Load Balancer (NLB) in AWS: The NLB will distribute traffic to multiple AWS resources across multiple Availability Zones.
• Create a VPC Endpoint Service Configuration: The VPC Endpoint Service Configuration points to the NLB and allows you to set up an AWS PrivateLink.
• Set up AWS PrivateLink on your Squid Proxy server: Your Squid Proxy server will connect to the AWS PrivateLink and use it to access the AWS resources.
• Set up IAM roles and policies to control access to AWS accounts: On the AWS side, you can control access to specific AWS accounts using IAM roles and policies.

Remember that this solution requires that your Squid Proxy server can connect to the AWS PrivateLink, and this may require additional network configuration on your corporate network.

Keep in mind that this is quite a complex setup and you would need someone with strong networking and AWS skills to implement this. If you're not sure how to proceed, you might want to engage with an AWS professional or consultant to help you set this up.

Please take a look at your proxy script, it is set to filter outgoing connections based on URLs. Since you want to limit access to specific AWS accounts, it might not be the ideal solution. Instead, you need more granular control on the AWS side, like controlling access through IAM roles and policies.

Also, note that AWS Management Console Private Access might not be available in all regions at the moment, which might cause issues if your AWS resources are spread across multiple regions. You might want to consider this when planning your implementation.

This is a difficult thing to do - you're trying to establish a data perimeter for the AWS console from your organisation.

Let's assume for a moment that your Squid proxy can be configured to allow internal users access only to the AWS console and no other external resources. You can do this by restricting access to specific destination IP ranges and HTTP hosts. That's relatively easy although the number of things you'll need to allow is quite high - the AWS console is a collection of services rather than a single entity.

However, that will not stop users from logging into other accounts using the console. Traffic through the Squid proxy will be encrypted (because access to the console is via HTTPS) so the content that the users are accessing is not visible to the proxy. So there's no easy way to have a filter that looks for the account number that the user is accessing.

As an organisation you can set up an identity provider to ensure that anyone logging into your accounts is properly authorised and the requests are originating from specific networks. I'd note that that sort of restriction (source networks) should be carefully used - it would be easy to get into a situation where emergency access is required to the console (say, while the corporate network is down) and that access is denied because the requests are not coming from the corporate network.

Finally, you could set up a process (I'm unsure whether Squid supports this or not) which intercepts and decrypts the HTTP sessions in order to perform the search for the authorised account numbers. I'm not a fan of this (even though it is relatively common) because it undermines the trust that users have in their sessions and network traffic being encrypted. It also opens up the proxy as a potential security hole should someone unauthorised gain access to it - they would have access to all the traffic flowing through it.

If it were me, this is something that needs to be solved at the client endpoint - that's where the user is; where the content is decrypted; where the URLs to be visited are known. Have some sort of endpoint protection software which checks what the user is doing and prohibits it if it is unauthorised. That's far easier than trying to get the network to perform application-layer security on encrypted traffic.