Summarize this content to 400 words in Persian Lang هنگام ساخت برنامه های کاربردی توزیع شده در AWS، سرویس صف ساده آمازون (SQS) اغلب به یک جزء حیاتی در مدیریت جریان پیام بین سرویس ها تبدیل می شود. اطمینان از امنیت این پیام ها مهم است، به ویژه در هنگام برخورد با داده های حساس در چندین حساب AWS. در این پست، گزینه‌های مختلف رمزگذاری موجود برای SQS را بررسی می‌کنیم و بهترین گزینه را برای سناریوهایی مانند دسترسی بین حساب‌ها انتخاب می‌کنیم.
رمزگذاری در حمل و نقل (همانطور که به آمازون SQS می رود و از آن می رود).
می‌توانید با استفاده از HTTPS (TLS) از داده‌های حین انتقال محافظت کنید. این تضمین می کند که پیام ها هنگام حرکت بین برنامه شما و SQS محافظت می شوند و از حملاتی مانند man-in-the-middle جلوگیری می کنند. با استفاده از HTTPS (TLS) فقط می توانید اتصالات رمزگذاری شده را اعمال کنید aws:SecureTransport شرط در خط مشی صف
“Condition”: {
“Bool”: {
“aws:SecureTransport”: “true”
}
}
یکی دیگر از گزینه‌های رمزگذاری در حین انتقال، استفاده از رمزگذاری سمت مشتری است که در آن داده‌ها را قبل از ارسال به SQS رمزگذاری می‌کنید. در اینجا شما باید مکانیزم رمزگذاری-رمزگشایی را خودتان مدیریت کنید.
رمزگذاری سمت سرور
رمزگذاری سمت سرور (SSE) با رمزگذاری محتویات صف شما در سطح ذخیره سازی، یک لایه امنیتی اضافی اضافه می کند. SSE از محتویات پیام ها در صف ها با استفاده از کلیدهای رمزگذاری مدیریت شده SQS (SSE-SQS) یا کلیدهای مدیریت شده در سرویس مدیریت کلید AWS (SSE-KMS) محافظت می کند.
SSE-SQS (کلیدهای مدیریت شده SQS)
این ساده ترین گزینه است که در آن Amazon SQS از کلیدهای رمزگذاری برای شما مراقبت می کند. SQS کلید رمزگذاری را تولید، مدیریت و استفاده می کند و نیازی به پیکربندی اضافی از جانب شما ندارد. از اکتبر 2022، این به طور پیش فرض برای هر صف SQS جدید فعال است.
SSE-KMS (کلیدهای سرویس مدیریت کلید AWS)
این گزینه با استفاده از سرویس مدیریت کلید AWS (KMS) برای مدیریت کلیدهای رمزگذاری، کنترل بیشتری را فراهم می کند. با SSE-KMS، می توانید از یک کلید KMS موجود استفاده کنید یا یک کلید جدید به طور خاص برای صف SQS خود ایجاد کنید. این روش در مقایسه با SSE-SQS، قابلیت های کنترل دسترسی و ممیزی دقیق تر را امکان پذیر می کند.
دسترسی بین حسابی با SSE
به عنوان یکی از پرکاربردترین خدمات پیام رسانی بین اجزای نرم افزار، دسترسی متقابل یک سناریوی بسیار رایج برای SQS است. با این حال، ما باید مطمئن شویم که پیام هایی که بین صف های SQS رد و بدل می شوند، ایمن هستند.
به طور کلی، می‌توانید با استفاده از خط‌مشی دسترسی SQS، دسترسی متقابل حساب را مدیریت کنید.
در زیر یک سیاست IAM از my_sqs_queue در حساب 111111111111. این حساب را اعطا کرده است 222222222222 برای ارسال پیام به my_sqs_queue.
{
“Sid”: “cross_account_access”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::222222222222:root”
},
“Action”: [
“sqs:GetQueueAttributes”,
“sqs:GetQueueUrl”,
“sqs:SendMessage”
],
“Resource”: “arn:aws:sqs:eu-west-1:111111111111:my_sqs_queue”,
}
}
بسته به رمزگذاری سمت سرور مورد استفاده در صف، مجوز بیشتری برای ارسال پیام به my_sqs_queue.
اگر از SSE-SQS استفاده شود
خبر خوب این است که اگر از SSE-SQS استفاده شود، هیچ مجوز اضافی مربوط به رمزگذاری برای حساب مورد نیاز نیست 222222222222. یعنی بالاتر از مجوز IAM برای ارسال پیام کافی است my_sqs_queue.
اگر از SSE-KMS استفاده شود
اگر از این رمزگذاری استفاده شود، مجوز اضافی برای کلید KMS باید تنظیم شود تا پیام‌ها با موفقیت ارسال شوند. my_sqs_queue.
بیایید فرض کنیم my_sqs_queue با استفاده از یک کلید KMS در همان حساب رمزگذاری می شود 111111111111 که نام مستعار دارد my_kms_key. در my_kms_key، باید برای حساب کاربری مجوز بدهید 222222222222 به شرح زیر:
{
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::222222222222:root”
},
“Action”: [
“kms:Encrypt”,
“kms:Decrypt”,
“kms:ReEncrypt*”,
“kms:GenerateDataKey*”,
“kms:DescribeKey”
],
“Resource”: “arn:aws:kms:eu-west-1:111111111111:key/[key-id]”
}
علاوه بر این، در حساب کاربری 222222222222، باید مجوز وجود داشته باشد kms:GenerateDataKey برای کلید KMS به شرح زیر است:
{
“Effect”: “Allow”,
“Action”: “kms:GenerateDataKey”,
“Resource”: “arn:aws:kms:eu-west-1:111111111111:key/[key-id]”
}
نتیجه گیری: چه روش SSE را انتخاب کنیم؟
هر دو SSE-SQS و SSE-KMS از دسترسی متقابل حساب برای صف های SQS پشتیبانی می کنند. تفاوت اصلی در میزان کنترل و مسئولیت شما بر فرآیند رمزگذاری نهفته است.
SSE-SQS زمانی ایده آل است که به رمزگذاری ساده و موثر بدون پیچیدگی اضافی مدیریت کلیدهای KMS نیاز دارید. برای اکثر موارد استفاده عمومی که سهولت راه اندازی و مدیریت در اولویت است ایده آل است.
زمانی که به کنترل بیشتری روی کلیدهای رمزگذاری خود نیاز دارید و نیاز به رعایت الزامات امنیتی و انطباق دقیق دارید، از SSE-KMS استفاده کنید. این گزینه برای محیط هایی مناسب است که مدیریت کلید و کنترل دسترسی دقیق ضروری است.
لینک های مفید
بهترین شیوه های امنیتی آمازون SQS: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDveloperGuide/sqs-security-best-practices.html#implement-server-side-encryption
رمزگذاری در حالت استراحت در Amazon SQS – راهنمای توسعه دهنده: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDveloperGuide/sqs-server-side-encryption.html
مدیریت کلید آمازون SQS – راهنمای توسعه دهنده: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDveloperGuide/sqs-key-management.html
هنگام ساخت برنامه های کاربردی توزیع شده در AWS، سرویس صف ساده آمازون (SQS) اغلب به یک جزء حیاتی در مدیریت جریان پیام بین سرویس ها تبدیل می شود. اطمینان از امنیت این پیام ها مهم است، به ویژه در هنگام برخورد با داده های حساس در چندین حساب AWS. در این پست، گزینه‌های مختلف رمزگذاری موجود برای SQS را بررسی می‌کنیم و بهترین گزینه را برای سناریوهایی مانند دسترسی بین حساب‌ها انتخاب می‌کنیم.
رمزگذاری در حمل و نقل (همانطور که به آمازون SQS می رود و از آن می رود).
می‌توانید با استفاده از HTTPS (TLS) از داده‌های حین انتقال محافظت کنید. این تضمین می کند که پیام ها هنگام حرکت بین برنامه شما و SQS محافظت می شوند و از حملاتی مانند man-in-the-middle جلوگیری می کنند. با استفاده از HTTPS (TLS) فقط می توانید اتصالات رمزگذاری شده را اعمال کنید aws:SecureTransport شرط در خط مشی صف
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
}
}
یکی دیگر از گزینه‌های رمزگذاری در حین انتقال، استفاده از رمزگذاری سمت مشتری است که در آن داده‌ها را قبل از ارسال به SQS رمزگذاری می‌کنید. در اینجا شما باید مکانیزم رمزگذاری-رمزگشایی را خودتان مدیریت کنید.
رمزگذاری سمت سرور
رمزگذاری سمت سرور (SSE) با رمزگذاری محتویات صف شما در سطح ذخیره سازی، یک لایه امنیتی اضافی اضافه می کند. SSE از محتویات پیام ها در صف ها با استفاده از کلیدهای رمزگذاری مدیریت شده SQS (SSE-SQS) یا کلیدهای مدیریت شده در سرویس مدیریت کلید AWS (SSE-KMS) محافظت می کند.
SSE-SQS (کلیدهای مدیریت شده SQS)
این ساده ترین گزینه است که در آن Amazon SQS از کلیدهای رمزگذاری برای شما مراقبت می کند. SQS کلید رمزگذاری را تولید، مدیریت و استفاده می کند و نیازی به پیکربندی اضافی از جانب شما ندارد. از اکتبر 2022، این به طور پیش فرض برای هر صف SQS جدید فعال است.
SSE-KMS (کلیدهای سرویس مدیریت کلید AWS)
این گزینه با استفاده از سرویس مدیریت کلید AWS (KMS) برای مدیریت کلیدهای رمزگذاری، کنترل بیشتری را فراهم می کند. با SSE-KMS، می توانید از یک کلید KMS موجود استفاده کنید یا یک کلید جدید به طور خاص برای صف SQS خود ایجاد کنید. این روش در مقایسه با SSE-SQS، قابلیت های کنترل دسترسی و ممیزی دقیق تر را امکان پذیر می کند.
دسترسی بین حسابی با SSE
به عنوان یکی از پرکاربردترین خدمات پیام رسانی بین اجزای نرم افزار، دسترسی متقابل یک سناریوی بسیار رایج برای SQS است. با این حال، ما باید مطمئن شویم که پیام هایی که بین صف های SQS رد و بدل می شوند، ایمن هستند.
به طور کلی، می‌توانید با استفاده از خط‌مشی دسترسی SQS، دسترسی متقابل حساب را مدیریت کنید.
در زیر یک سیاست IAM از my_sqs_queue در حساب 111111111111. این حساب را اعطا کرده است 222222222222 برای ارسال پیام به my_sqs_queue.
{
"Sid": "cross_account_access",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": [
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:eu-west-1:111111111111:my_sqs_queue",
}
}
بسته به رمزگذاری سمت سرور مورد استفاده در صف، مجوز بیشتری برای ارسال پیام به my_sqs_queue.
اگر از SSE-SQS استفاده شود
خبر خوب این است که اگر از SSE-SQS استفاده شود، هیچ مجوز اضافی مربوط به رمزگذاری برای حساب مورد نیاز نیست 222222222222. یعنی بالاتر از مجوز IAM برای ارسال پیام کافی است my_sqs_queue.
اگر از SSE-KMS استفاده شود
اگر از این رمزگذاری استفاده شود، مجوز اضافی برای کلید KMS باید تنظیم شود تا پیام‌ها با موفقیت ارسال شوند. my_sqs_queue.
بیایید فرض کنیم my_sqs_queue با استفاده از یک کلید KMS در همان حساب رمزگذاری می شود 111111111111 که نام مستعار دارد my_kms_key. در my_kms_key، باید برای حساب کاربری مجوز بدهید 222222222222 به شرح زیر:
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:eu-west-1:111111111111:key/[key-id]"
}
علاوه بر این، در حساب کاربری 222222222222، باید مجوز وجود داشته باشد kms:GenerateDataKey برای کلید KMS به شرح زیر است:
{
"Effect": "Allow",
"Action": "kms:GenerateDataKey",
"Resource": "arn:aws:kms:eu-west-1:111111111111:key/[key-id]"
}
نتیجه گیری: چه روش SSE را انتخاب کنیم؟
هر دو SSE-SQS و SSE-KMS از دسترسی متقابل حساب برای صف های SQS پشتیبانی می کنند. تفاوت اصلی در میزان کنترل و مسئولیت شما بر فرآیند رمزگذاری نهفته است.
SSE-SQS زمانی ایده آل است که به رمزگذاری ساده و موثر بدون پیچیدگی اضافی مدیریت کلیدهای KMS نیاز دارید. برای اکثر موارد استفاده عمومی که سهولت راه اندازی و مدیریت در اولویت است ایده آل است.
زمانی که به کنترل بیشتری روی کلیدهای رمزگذاری خود نیاز دارید و نیاز به رعایت الزامات امنیتی و انطباق دقیق دارید، از SSE-KMS استفاده کنید. این گزینه برای محیط هایی مناسب است که مدیریت کلید و کنترل دسترسی دقیق ضروری است.
لینک های مفید
- بهترین شیوه های امنیتی آمازون SQS: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDveloperGuide/sqs-security-best-practices.html#implement-server-side-encryption
- رمزگذاری در حالت استراحت در Amazon SQS – راهنمای توسعه دهنده: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDveloperGuide/sqs-server-side-encryption.html
- مدیریت کلید آمازون SQS – راهنمای توسعه دهنده: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDveloperGuide/sqs-key-management.html
