- Newest
- Most votes
- Most comments
We support SourceIP as an authorization element when using Custom Identity Provider. See https://aws.amazon.com/about-aws/whats-new/2020/06/aws-transfer-family-enables-source-ip-as-a-factor-for-authorization/
Part of the information provided to the Custom IDP Lambda is the Source IP to allow fine grain authorization. If using the API_GATEWAY integration you have the additional benefit of available WAF to make more expressive rules based on SourceIP information.
You can create a session policy based on the SourceIP provided and return that as part of the initial authentication response which would then allow better restriction and fully enable you to make different access controls based on the SourceIP.
I would deploy the server inside a VPC and this use the Security Group that you assign to the endpoint to only allow those approved CIDRs. See: Create an internet-facing endpoint for your server. Might not work for you because it would restrict all interaction.
Hi,
I believe that AWS Transfer Family feature named Fine-Grain Access Control (FGCAC) is what you need as you can identiy your users
Best,
Didier
Hi Didier,
Thanks for sharing the link. I think the above approach would be a good fit if we control access based on user-to-folder structure. Let me put my use case which is a little different.
- We have 2 users who will be accessing the file transfer server from multiple systems let's say 10 different systems.
- Both users can access file transfer from all 10 systems but are limited to sftp actions on some systems e.g. Allow Put and get operations on 6 systems and Only Get operations remaining 4 systems.
- The only unique thing about each system is an IP address we have every user's Cloudwatch session log of file transfer and we know if the user logged from one specific IP, if that IP belongs to the first 6 or the rest 4 systems.
I hope this clarifies my use case.
Thanks
until this point, I have solution and it seems working but I am not able to restrict operations like Get or Put to specific server.
Given all your requirements I think the only way you could do this is if you can restrict your users to using a custom SFTP client and a custom authorizer. The custom client would initiate a Cognito user auth, then would hit a new Lambda that would check the IP and issue a nonce back to the custom client if the action is allowed. The client would then start the transfer with the nonce as the password and Transfer Service would hit the custom authorizer. The custom authorizer would submit the nonce back to the first service which would validate it and send a 400 (or whatever) back to the custom authorizer if the nonce is good. The reason for using a nonce is that a Cognito access token is too long to fit in the SFTP custom auth password field (which looks to have a limit of 1024 chars). I've been building out a similar flow, minus the IP checking, as a SSO POC using a simple Amplify Flutter client. STS might be able to manage the nonce but I haven't got that far to determine that yet, if no I'll use ElastiCache.
Relevant content
- asked 2 years ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 3 years ago
Thanks, Kentrad, We already using WAF to control access based on source IP and yes, security group option cannot control specific option like only PUT or GET.
I don't think there is direct way to solve this problem, using the SourceIP in authorization decisions. I wonder if using two servers would provide a work around. Where one server is used for Get/Put and one for Get, allowing only the SourceIPs were needed. Both servers will point to the same backend storage but use different access points with difference access point policies, as described above/below.