New answers tagged

1

Solution #1 is viable but only if the source bucket is versioned and the Lambda function writes to a database that supports strongly consistent reads, because that's the only way you can tell authoritatively whether you're doing it "only once for the first time." When you ask S3 about the existence of an object for the very first time ever using a ...


0

So actually both options are OK. Cold-start is only really an issue for languages like Java, for javascript and python cold-start times are pretty minimal, and not really an issue if there is continuous volume on the bucket. The lambda would trigger for each new object in the bucket, but would only copy across if there are no previous versions of the file. ...


4

tl/dr: As long as the bucket is not publicly accessible (i.e. you need access keys to read/write), then don't worry about the name. It isn't private because your employees probably know it and hackers/penetration testers routinely perform brute-force searches for bucket names. Also, asking "What if someone figures out how to hack buckets?" is like ...


3

Unfortunately, the answer is "It depends". But first, we need to clear up that KMS keys and Buckets are mutually independent, one KMS key (called a CMK) can be tied to multiple buckets, and one bucket can have objects encrypted by multiple CMKs. Secondly, because of the tight integration between KMS and S3, the only real access control we have is via key ...


1

IMHO, you should examine the whole thing in terms of costs/benefits and risk/mitigation. As you store data in non controled storage, you store it in encrypted form. Ok: the risk is that someone (possibly a staff member of the hosting service) can access the data the mitigation is to encrypt the data the cost is to implement encryption and maintain the ...


4

One argument in favour of separate keys: assume at some point in the future your app has some sort of SQLInjection or Server-side request forgery (SSRF) vulnerability that lets a user logged in as CustomerA bypass the usual access control rules and fetch data belonging to CustomerB. If all customers use the same key, then your application layer server will ...


2

Word of advice: It's great that you are reaching out, but medical data is particularly sensitive and handling should be done by an experienced developer and the code should be peer reviewed. There is a lot at stake here and too many things can go wrong. That said you need to take several aspects into consideration. The first thing you need to do is a ...


Top 50 recent answers are included