Situation
We have a web app hosted on Amazon EC2. It's intended to be used only by a few users in a company.
How we're dealing with this
- We share the (Elastic) IP address of the instance with the users.
- We add each user's IP address to the security group of the instance as and when needed.
When I say as and when needed, I mean emails from the users complaining that the web portal is showing an error page. They forget that this step of including the IP in the security group is required (and I don't blame them; they're end users).
For the sake of this question, let's assume we have a total of 5 users in a company who need this access. IP addresses of User-1 and User-2 have already been added to the security group.
Problems
- User-3 goes to the IP address directly, but isn't able to access it as the user's IP address hasn't been added to the security group.
- If User-1 or User-2 restart their internet, their IP address will likely change (dynamic IP provided by ISP) and the new IP address will have to be added to the security group (and the old one will have to be revoked to avoid access by others).
Other options I'm considering
- Provide access only to their office VPN and ask all users to connect through it.
- (Very cumbersome for the user) Ask the users to log in to the AWS management console, go to EC2 service, go to Security Groups section and add their IP addresses manually (the users already have AWS IAM users and appropriate permissions to perform this).
- Create a script that adds the user's current IP to the security group (using AWS CLI / SDK) - sounds very dangerous and inappropriate as we'll have to include someone's API credentials in the script.
Option 4 - stop controlling the access through Security Groups and instead implement some decent authentication mechanism.
For example put an Application Load Balancer in front of the web app and configure the ALB to require Cognito authentication. Only authenticated users will make it through the ALB to your web app - problem solved. The Cognito can have local users or can be used together with your Azure AD or if you use Office365 in your organisation. This is quite a transparent way that doesn't require any changes to the app.
Alternatively if your web app supports it you should configure it to require SAML auth against whatever user directory your org is using - Office365, G-Suite, etc.
Hope that helps :)
Option 5 - stop managing Security Groups (essentially IP-based firewalls) and use TLS Client Certificates.
If you're using modern user management systems like Azure AD or LDAP, you already have the right tool to issue and distribute the certificates. You'll setup a private CA and configure the HTTP server (Nginx, Apache2 or AWS ALB) to authenticate by certificates. Whoever without a certificate, or with an invalid certificate (including expired ones) will not make it through the HTTP server. This requires zero change to the web app itself, and you can even drop any authentication in the app as certificates can serve that purpose in addition to access control.
One bonus point is that this works everywhere - be it AWS, Azure or your on-premises infrastructure. You can even reuse the exact same stack of credentials and configuration (except for AWS ALB) just fine.