Skip to content

AWS Transfer Family: Directory Service vs Lambda AD integration

0

Hi,

I am pondering the use of AWS Directory Service vs Lambda to integrate with a 3rd party IdP. As I understand, Directory Service is exclusively to integrate with AD/AAD, where as Lambda can be used to integrate with any IdP.

That being said, in the context of AD/AAD, the Lambda function would receive the user credentials in clear before asking AD/AAD to authenticate the user (see ref. here). By using Directory Service instead, I would delegate the whole auth process, never gaining knowledge of the user creds, which to me is more secure as the Lambda function (which is a custom code) is subject to errors and ill intentions.

Am I missing something or is there a way to prevent the Lambda function from manipulating such sensitive data?

Regards

1 Answer
1
Accepted Answer

For password-based authentication, it's the primary function of the Lambda function to validate the username and password, so there's no way to prevent the function from receiving them.

If you use SSH keys instead of passwords to authenticate, the Lambda function will only receive the username, and it'll only return the public SSH key(s) valid for the user. This would avoid the need for the secret part of any credentials to be known by either the Lambda function or even the Transfer server.

You're quite right that if you use the AWS-provided method for authenticating to AD DS (whether self- or AWS-managed, or Azure-hosted) via AWS Directory Service, that AWS-provided solution takes the processing of credentials out of the customer's hands.

In my environment, we use Lambda functions to authenticate users but for users unable to use SSH keys to authenticate, we generate random credentials dedicated for use with the SFTP service. This avoids the risk of end users' personal secrets being involved in any way. We also use the Lambda function to check that the IP address of the user matches allowed CIDRs for that specific user. Even if credentials were leaked from one of our partners, for example, they'd be worthless almost invariably, because while the credentials would be correct, they simply wouldn't be accepted from anywhere except the legitimate IPs for the user.

The built-in authentication features don't support per-user IP restrictions, so you might want to take that into consideration.

As a final layer of defence, we use IAM permissions (which the Transfer server allows configuring via IAM roles exclusively or in combination with IAM session policies) to permit only list and upload (+ optionally delete) access to users/folders where data is only expected to be uploaded, and we allow list and download (+delete) access to the folders used for downloads. Even in the very unlikely case that credentials got compromised and used from the exact IPs permitted for just that user (as might happen if one of our partners' data centre or VPN were compromised), the bad actor wouldn't be able to steal any of the data that the legitimate user had uploaded earlier. They would only get their hands on data that's pending downloading (i.e., not yet picked up and deleted) by that user.

EXPERT

answered 2 years ago

EXPERT

reviewed 2 years ago

EXPERT

reviewed 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.