سياسة IAM وbucket للوصول إلى S3

الدعم تثبيت
1

لاحظت أن جميع الدروس التي وجدتها حول الوصول إلى S3 في Discourse تمنح المستخدم سلطة مطلقة على الـ bucket — فهي تسمح بصلاحية ‘s3:*’.

تُعد هذه السياسة غير حكيمة للغاية، إذ تمنح تحكمًا أكبر بكثير في الـ bucket مما هو معقول. فإذا كنت تستخدم S3 لتخزين نسخ احتياطية لـ Discourse، فإن مهاجمًا متعطشًا للتخريب سيكون قادرًا على حذف الـ bucket والنسخ الاحتياطية الخاصة بك أثناء انسحابه.

هناك طريقتان لمقاومة ذلك: الأولى، سياسة أكثر تقييدًا…

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:List*",
                "s3:Get*",
                "s3:AbortMultipartUpload",                
                "s3:DeleteObject",               
                "s3:PutObject"               
            ],
            "Resource": [
                "arn:aws:s3:::whatever-bucket",
                "arn:aws:s3:::whatever-bucket/*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:HeadBucket"
            ],
            "Resource": "*"
        }
    ]
}

… والثانية، تطبيق بعض الاحتياطات المعقولة على سياسة الـ bucket. (في الواقع، هذا يتجاوز بكثير الحد الأدنى المطلوب فعليًا، لكنني كنت مستعجلًا ولم يكن لدي وقت للتجربة، وهو أفضل مما وجدت.) أنصحك بتفعيل نسخ الإصدارات (versioning)، ثم إعداد قاعدة دورة حياة (lifecycle rule) لـ “الإصدارات السابقة” بحيث يتم حذفها بعد فترة زمنية معقولة، مثل 21 يومًا. السياسة المذكورة ستسمح بتدوير السجلات وحذف الملفات، لكنها لن تمنح المستخدم الذي يحمل بيانات اعتماد S3 صلاحية استعادة أو حذف الإصدارات السابقة، مما يعني أنه رغم إمكانية حذفه للنسخة الاحتياطية، فإن مهاجمًا متعطشًا للتخريب لن يتمكن من مسحها من سجل الإصدارات قبل أن يتمكن مدير بصلاحيات الجذر (root) من إنقاذها.

شكرًا لك!

2

This is good advice, certainly, but I’m unsure Discourse should really be considered responsible for giving out advice about S3 best practices?

We could put a note / reminder in the help text for the field, if it can be kept short.

3

Oh, I’m sorry – I wasn’t trying to suggest you /should/ be; certainly I don’t know where you’d put it. I just found that when I Googled “Discourse S3 IAM” all of the example policies were the same awful wide-open one, so I’m reporting what I did instead of that.

(That’s why I seperated this thread from the other.)

4

Were those examples here on meta.discourse.org? If they’re in a howto you might be able to edit them, or you could draft your own and get it moved into #howto:sysadmin.

5

My take on this is that our responsibility for S3 advice is about the same as our advice on things like TLS configs (which we do update on occasion). We should try to stay “safe by default”, because we know that just about everyone’s going to blindly use whatever we suggest, because very few people know what any of this magic actually does. Our as-close-to-official-as-we-get guide on setting up S3 does suggest using the wide-open policy, so I’ll fix that up to be more sensible.

@Asher_Densmore-Lynn: if you find any other examples of problematic IAM policies floating around anywhere we can control (here on meta, git repos under the discourse GitHub user, that sort of thing), feel free to let us (me) know (with a specific reference to what’s problematic; everyone’s Google search results are different), and I’ll get it fixed.

6

Sure, and thanks! I hope you add the part about the bucket versioning – keeping your backups safe from catastrophe is hard to do when you have to allow rotation and deletion. If you need me to go into more detail or explain it better I’ll be happy to oblige.

7

One thing to bear in mind is that the howto I linked above is about asset upload, not backups. The policy required for that is likely to be somewhat different to one required for backups. Also, that howto assumes that Discourse will be creating the bucket, and adding instructions on manually adding versioning and rotation would significantly complicate what is already a bit of a bear of a process. If the versioning/rotation settings can be set at creation time (without opening up the IAM policy to allow an attacker to remove those attributes later), then a PR to Discourse to add that ability (even by default) wouldn’t be a bad idea. Otherwise, I think it’s best if you write a separate “Discourse S3 201: Securitay!” topic, that can be linked from the main howto.

8

I looked at that setup guide – be aware that that bucket creation will fail with those permissions. You’ll want to add s3:CreateBucket if that’s something you want to keep.

9

I already added that action.