دفاع در عمق یک رویکرد لایه ای برای مدیریت آسیب پذیری است که ریسک را کاهش می دهد.
مقدمه
AWS انواع خدمات امنیتی را ارائه می دهد که می توانند به روش های مختلف و برای انواع مختلف دفاع مورد استفاده قرار گیرند. وقتی صحبت از امنیت به میان می آید، ما رویکردهای متعددی برای دفاع موثر از زیرساخت خود داریم. ما درک می کنیم که امنیت مهمترین جنبه زیرساخت ما است. در این دمو، من رویکرد دفاع در عمق را با استفاده از سرویس‌های مختلف AWS پیاده‌سازی می‌کنم. من زیرساختی را با یک برنامه کاربردی پایه که روی نمونه EC2 اجرا می شود راه اندازی می کنم. برای پیاده سازی رویکرد دفاع در عمق، یک VPC سفارشی برای استفاده از زیرشبکه های سفارشی و ACL ایجاد می کنم و همچنین از EC2، Application Load Balancer، Web Application Firewall، Route 53 و Amazon Certificate Manager استفاده خواهم کرد.
رجوع کنید به لیبمن (1996): “مفهوم دفاع در عمق نه تنها راهنمایی برای بررسی یک راه حل فنی خاص به عنوان مثال، مجموعه ای از موانع منحصر به فرد است، بلکه یک روش استدلال و یک چارچوب کلی برای بررسی بیشتر است. به طور کامل کل تأسیسات، هم برای طراحی و هم برای تجزیه و تحلیل آن».
پیش نیازها
- ایجاد حساب AWS من قبلاً یک حساب AWS دارم و حساب جدیدی ایجاد نخواهم کرد.
- Terraform را در ماشین محلی خود نصب کنید.
- این یک است هشدار هشدار. این نسخه ی نمایشی می تواند هزینه های کمی را از حساب شما ایجاد کند. شما باید مقداری پول در حساب خود داشته باشید.
VPC سفارشی ایجاد کنید
طبق اسناد AWS، VPC یک شبکه مجازی منطقی ایزوله است که شما تعریف کرده اید. این شبکه مجازی با مزایای استفاده از زیرساخت مقیاس پذیر AWS شباهت زیادی به یک شبکه سنتی دارد که در مرکز داده خود کار می کنید.
اگر در پروفایل متوسط من مشترک شده باشید، ممکن است داستان من “چگونه یک AWS VPC با استفاده از کنسول یا Terraform بسازیم” را دیده باشید. من یکی دیگر را با استفاده از Terraform ایجاد خواهم کرد. اگر با Terraform آشنایی ندارید، من همچنین نحوه ایجاد VPC در کنسول AWS را توضیح دادم. لازم به ذکر است که در داستان قبلی از “eu-central-1” استفاده کردم و اکنون آن را به “us-east-1” تغییر خواهم داد.
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags = {
Name = "ahmed-srebrenica-vpc"
}
}
resource "aws_subnet" "public_a" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
map_public_ip_on_launch = true
availability_zone = "us-east-1a"
tags = {
Name = "ahmed-srebrenica-public-subnet-a"
}
}
resource "aws_subnet" "public_b" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.3.0/24"
map_public_ip_on_launch = true
availability_zone = "us-east-1b"
tags = {
Name = "ahmed-srebrenica-public-subnet-b"
}
}
resource "aws_subnet" "private_a" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.2.0/24"
availability_zone = "us-east-1a"
tags = {
Name = "ahmed-srebrenica-private-subnet-a"
}
}
resource "aws_subnet" "private_b" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.4.0/24"
availability_zone = "us-east-1b"
tags = {
Name = "ahmed-srebrenica-private-subnet-b"
}
}
resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
tags = {
Name = "ahmed-srebrenica-igw"
}
}
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
tags = {
Name = "ahmed-srebrenica-public-rt"
}
}
resource "aws_route_table_association" "public_association_a" {
subnet_id = aws_subnet.public_a.id
route_table_id = aws_route_table.public.id
}
resource "aws_route_table_association" "public_association_b" {
subnet_id = aws_subnet.public_b.id
route_table_id = aws_route_table.public.id
}
resource "aws_route" "public_route" {
route_table_id = aws_route_table.public.id
destination_cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
resource "aws_nat_gateway" "nat" {
allocation_id = ""
subnet_id = aws_subnet.public_a.id
connectivity_type = "private"
tags = {
Name = "ahmed-srebrenica-nat-gateway"
}
}
resource "aws_route_table" "private" {
vpc_id = aws_vpc.main.id
tags = {
Name = "ahmed-srebrenica-private-rt"
}
}
resource "aws_route_table_association" "private_association_a" {
subnet_id = aws_subnet.private_a.id
route_table_id = aws_route_table.private.id
}
resource "aws_route_table_association" "private_association_b" {
subnet_id = aws_subnet.private_b.id
route_table_id = aws_route_table.private.id
}
resource "aws_route" "private_route" {
route_table_id = aws_route_table.private.id
destination_cidr_block = "0.0.0.0/0"
nat_gateway_id = aws_nat_gateway.nat.id
}
در تصویر زیر می بینید که من VPC خود را با موفقیت ایجاد کردم و نام آن را “ahmed-srebrenica-vpc” گذاشتم. من 4 زیرشبکه (2 زیرشبکه عمومی و 2 زیرشبکه خصوصی)، جدول مسیرهای عمومی و خصوصی، یک دروازه اینترنت و یک دروازه NAT دارم. برای این نسخه ی نمایشی، ما به زیرشبکه های خصوصی نیاز نداریم، اما اگر می خواهید یک پایگاه داده اضافه کنید، باید زیرشبکه های خصوصی داشته باشید.
بیایید خلاصه کنیم: هر بار که یک پروژه جدید را شروع می کنید، یک VPC سفارشی ایجاد کنید. هرگز از VPC پیش فرض استفاده نکنید. ما تاکنون یک VPC سفارشی با دو زیرشبکه عمومی و خصوصی ایجاد کرده ایم. VPC سفارشی ما دارای لیست کنترل دسترسی به شبکه است، ما بعداً برخی از قوانین را برای آن تغییر خواهیم داد.
دو نمونه EC2 و یک گروه امنیتی برای آن ایجاد کنید
نمونه EC2 مانند یک ماشین مجازی اما در فضای ابری است. Security Group حالتی است و به عنوان یک فایروال مجازی برای نمونه های EC2 شما برای کنترل ترافیک ورودی و خروجی عمل می کند.
حرکت بعدی ما ایجاد یک گروه امنیتی خواهد بود. برای انجام این کار، به داشبورد EC2 بروید و از سمت چپ “گروه های امنیتی” را انتخاب کنید و سپس روی دکمه “ایجاد گروه امنیتی” کلیک کنید.
شما باید گروه امنیتی خود را نام ببرید و فراموش نکنید که VPC سفارشی که در مرحله اول ایجاد کرده اید را انتخاب کنید. پورت های 80 و 443 را از قوانین ورودی باز کنید.
روی دکمه “ایجاد گروه امنیتی” کلیک کنید.
قدم بعدی ما ایجاد یک نمونه EC2 و راه اندازی Nginx است. به داشبورد EC2 بروید و از سمت چپ “Instances” را انتخاب کنید، سپس روی دکمه “Launch Instances” کلیک کنید.
اولین قدم ما این است که نام نمونه را بگذاریم و Amazon Linux 2023 AMI را انتخاب کنیم.
نوع نمونه باید t2.micro باشد و جفت کلید اختیاری است.
این مهمترین مرحله است. در قسمت “تنظیمات شبکه”، VPC سفارشی و زیرشبکه عمومی خود را انتخاب کنید، اختصاص خودکار IP عمومی را فعال کنید و گروه امنیتی را که قبلا ایجاد کرده اید انتخاب کنید.
با 8 گیگابایت فضای ذخیره سازی بروید و روی «جزئیات پیشرفته» کلیک کنید.
به پایین صفحه بروید و در قسمت «اطلاعات کاربر» این کد را قرار دهید:
#!/bin/bash
sudo yum install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
echo "Hello Friend from $(hostname -f)" > /usr/share/nginx/html/index.html
روی دکمه “راه اندازی نمونه” کلیک کنید.
نمونه دیگری را با همان پیکربندی راه اندازی کنید و فقط زیر شبکه را تغییر دهید. این بار subnet-b را انتخاب کنید.
2 تا 3 دقیقه صبر کنید و خواهید دید که نمونه های EC2 با موفقیت ایجاد شده اند.
بیایید خلاصه کنیم: ما دو نمونه EC2 ایجاد کرده ایم. برای دستیابی به دسترسی بالا، یک نمونه EC2 را در public-subnet-a با استفاده از us-east-1a و نمونه EC2 دیگر را در public-subnet-b با استفاده از us-east-1b راه اندازی کردیم. ما گروه‌های امنیتی را برای نمونه‌ها ایجاد کرده‌ایم که به پورت‌های 80 و 443 اجازه می‌دهد. گروه امنیتی به عنوان یک دیوار آتش برای نمونه‌های EC2 ما عمل می‌کند.
یک Application Load Balancer ایجاد کنید
طبق اسناد AWS، Elastic Load Balancing به طور خودکار ترافیک ورودی شما را در چندین هدف، مانند نمونه‌های EC2، کانتینرها و آدرس‌های IP، در یک یا چند منطقه دسترسی توزیع می‌کند. بر سلامت اهداف ثبت شده خود نظارت می کند و ترافیک را فقط به اهداف سالم هدایت می کند. Elastic Load Balancing با تغییر ترافیک ورودی شما در طول زمان، بار متعادل کننده شما را مقیاس می کند. می تواند به طور خودکار در اکثریت قریب به اتفاق بارهای کاری مقیاس شود. متعادل کننده بار برنامه به عنوان تنها نقطه تماس برای مشتریان عمل می کند. Application load balancer ترافیک ورودی برنامه را در چندین هدف، مانند نمونه های EC2، در چندین منطقه در دسترس توزیع می کند. این در دسترس بودن برنامه شما را افزایش می دهد.
قدم بعدی ما ایجاد یک گروه هدف برای Application Load Balancer است. به داشبورد EC2 بروید و از سمت چپ، Target Groups و سپس دکمه “Create Target Group” را انتخاب کنید.
در قسمت Basic Configuration Instances را انتخاب کنید و گروه هدف خود را نام ببرید.
پروتکل باید HTTP باشد و فراموش نکنید که VPC سفارشی خود را انتخاب کنید.
همه چیز را به عنوان پیش فرض بگذارید و روی دکمه “بعدی” کلیک کنید.
اکنون باید اهداف را ثبت کنیم. هر دو نمونه را انتخاب کنید و روی دکمه “شامل به عنوان در انتظار زیر” کلیک کنید. پس از آن، روی دکمه “ایجاد گروه هدف” کلیک کنید.
عالی، ما با موفقیت گروه هدف را ایجاد کردیم.
اکنون باید یک Application Load Balancer ایجاد کنیم. از سمت چپ، Load Balancer و سپس دکمه “Create Load Balancer” را انتخاب کنید.
ALB خود را نامگذاری کنید، Scheme باید اینترنت باشد، نوع آدرس باید IPv4 باشد.
VPC سفارشی خود و هر دو زیرشبکه Public را انتخاب کنید.
عالی است، قدم بعدی ما ایجاد یک گروه امنیتی دیگر است، اما این بار، گروه باید با Application Load Balancer مرتبط شود. روی «ایجاد یک گروه امنیتی جدید» کلیک کنید.
یک گروه امنیتی با پورت باز شده 443 ایجاد کنید.
به Load Balancer برگردید و Security Group جدید را انتخاب کنید.
در قسمت Listeners and Routing، این Listeners and Configuration را انتخاب کنید.
ما باید حفاظت WAF را فعال کنیم.
همه چیز را به عنوان پیش فرض بگذارید و روی دکمه “ایجاد متعادل کننده بار” کلیک کنید.
چند دقیقه منتظر بمانید تا پیام «تعادل کننده بار با موفقیت ایجاد شد». نام DNS را کپی کرده و در مرورگر خود پیست کنید تا ببینید آیا همه چیز درست کار می کند یا خیر.
Application Load Balancer با موفقیت ایجاد شد و به درستی کار می کند.
Btw. این نمای کلی ترافیک WAF پس از چند ساعت است.
بیایید خلاصه کنیم: در این مراحل، ما با موفقیت یک Application Load Balancer را در مقابل دو نمونه EC2 ایجاد کردیم. Application Load Balancer به عنوان یک سرور عمل می کند و ترافیک را بین نمونه های EC2 توزیع می کند. مزایای امنیتی متعددی در رابطه با Application Load Balancer وجود دارد. SSL/TLS را ارائه می دهد و از ما در برابر حملات DDoS محافظت می کند. ما همچنین یک لایه امنیتی دیگر را با گروه امنیتی متصل به Application Load Balancer اضافه می کنیم.
ما فایروال Web Application را ضمیمه کردیم، این به محافظت از برنامه های کاربردی وب شما در برابر سوء استفاده های رایج در لایه برنامه که می تواند بر در دسترس بودن یا مصرف منابع بیش از حد تأثیر بگذارد، کمک می کند. ما از تنظیمات پیش فرض WAF استفاده خواهیم کرد.
رکوردهای مسیر 53 را ایجاد کنید
مسیر 53 چیست؟ طبق اسناد AWS، Route 53 یک سرویس وب سیستم نام دامنه (DNS) بسیار در دسترس و مقیاس پذیر است. شما می توانید از Route 53 برای انجام سه عملکرد اصلی در هر ترکیبی استفاده کنید: ثبت دامنه، مسیریابی DNS و بررسی سلامت.
قدم بعدی ما ایجاد رکوردهای جدید در Hosted Zones خواهد بود. به Route 53 در کنسول خود بروید و از سمت چپ “Hosted Zones” را انتخاب کنید. من قبلا دامنه ahmedsrebrenica.com را دارم.
به نام دامنه خود بروید و روی دکمه “ایجاد رکورد” کلیک کنید.
رکورد خود را نام ببرید، نوع رکورد را انتخاب کنید و TTL باید 60 ثانیه باشد. نام مستعار را فعال کنید و ترافیک را به Application Load Balancer هدایت کنید. منطقه us-east-1 را انتخاب کنید و DNS Load Balancer را انتخاب کنید. روی دکمه “ایجاد رکورد” کلیک کنید.
ما با موفقیت یک رکورد جدید ایجاد کردیم. باید یک رکورد جدید اضافه کنیم، این بار با www.
بیایید خلاصه کنیم: ما با موفقیت نام دامنه را برای نسخه آزمایشی خود ایجاد کرده ایم. با این حال، این نام های دامنه گواهینامه SSL ندارند.
با استفاده از AWS Certificate Manager گواهی های SSL/TLS ایجاد کنید
«مدیر گواهی AWS (ACM) پیچیدگی ایجاد، ذخیره و تمدید گواهی‌ها و کلیدهای عمومی و خصوصی SSL/TLS X.509 را که از وب‌سایت‌ها و برنامه‌های AWS شما محافظت می‌کنند، کنترل می‌کند.»
در کنسول خود، سرویس Certificate Manager را جستجو کنید. شما باید این را ببینید. روی دکمه “درخواست گواهی” کلیک کنید.
نام ها باید همان نام هایی باشند که در سرویس Route 53 ایجاد کرده اید. بقیه موارد را به حالت پیش فرض رها کنید و روی دکمه “درخواست” کلیک کنید.
ما با موفقیت گواهی ها را ایجاد کردیم. گام بعدی ما ایجاد یک رکورد Route 53 دیگر است، اما این بار با نام‌های CNAME و مقادیر CNAME از گواهی‌های ما.
به مسیر 53 بروید و دوباره روی دکمه “ایجاد رکورد” کلیک کنید. نام‌های CNAME را از مدیر گواهی به نام رکورد، نوع رکورد CNAME را انتخاب کنید و مقادیر CNAME را از مدیر گواهی در کادر ارزش جای‌گذاری کنید. روی دکمه “ایجاد رکورد” کلیک کنید.
تمام شد، کار ما با مسیر 53 تمام شد.
بیایید خلاصه کنیم: برای ایمن سازی نام دامنه خود، گواهی هایی را با استفاده از سرویس ACM اضافه کردیم.
شنونده جدیدی اضافه کنید (HTTPS:443) و موجود را ویرایش کنید (HTTP:80)
مرحله آخر ما اضافه کردن 443 شنونده به Application Load Balancer موجود است. به قسمت Load Balancer رفته و Load Balancer موجود را انتخاب کنید. روی دکمه «افزودن شنونده» کلیک کنید.
فقط پیکربندی را از روی اسکرین شات دنبال کنید. پروتکل باید HTTPS، پورت 443 و Forward to the target group شما باشد.
Certificate from ACM را انتخاب کنید و روی دکمه “Add” کلیک کنید.
دامنه خود را در مرورگر بررسی کنید وب سایت را مشاهده خواهید کرد.
آخرین مرحله ویرایش HTTP:80 Listener موجود است. HTTP:80 را انتخاب کنید و روی Edit Listener کلیک کنید.
از Forward به گروه های هدف به تغییر مسیر به URL تغییر دهید و پورت باید 443 باشد. روی دکمه “ذخیره تغییرات” کلیک کنید.
بسیار خوب، ما تغییر مسیر عمل مسیریابی را روی HTTPS در پورت 443 تنظیم کردیم.
بیایید خلاصه کنیم: ما یک شنونده HTTPS:443 برای نظارت بر ترافیک HTTPS در پورت 443 اضافه کرده‌ایم. علاوه بر این، شنونده HTTPS را برای تغییر مسیر از درگاه HTTP 80 به پورت HTTPS 443 به‌روزرسانی کرده‌ایم. همچنین یک گواهی از ACM به HTTPS اضافه کرده‌ایم: 443 شنونده، به ما امکان می دهد از نام دامنه خود با SSL به درستی استفاده کنیم.
ACL های شبکه را تغییر دهید
یک لیست کنترل دسترسی به شبکه (ACL) ترافیک ورودی یا خروجی خاصی را در سطح زیرشبکه اجازه یا رد می کند. برای ایجاد امنیت بهتر، باید قوانین لیست کنترل دسترسی را تغییر دهیم. به VPC سفارشی خود بروید و از سمت چپ Network ACLs را انتخاب کنید. روی دکمه «ویرایش قوانین ورودی» کلیک کنید.
نوع را از تمام ترافیک به HTTPS (443) تغییر دهید، زیرا می‌خواهیم فقط ترافیک HTTPS را مجاز کنیم، نه چیز دیگری. روی دکمه “ذخیره تغییرات” کلیک کنید.
ACL ها بدون حالت هستند و در مقایسه با گروه های امنیتی، باید قوانین خروجی را ویرایش کنیم و پورت های زودگذر را باز کنیم (محدوده پورت 1024-65535).
بیایید ببینیم که آیا همه چیز درست کار می کند یا خیر. وب سایت خود را بررسی کنید.
بیایید خلاصه کنیم: فهرست کنترل دسترسی به شبکه (NACL) یک لایه امنیتی اضافی است که از زیرشبکه های ما محافظت می کند. ما فقط به 443 ترافیک اجازه داده ایم، و چون NACL بدون حالت است، پورت های زودگذر را در بخش Outbound خود باز کرده ایم.
به صورت اختیاری می توانید CloudFront را راه اندازی کنید
با استفاده از CloudFront در کنار Application Load Balancer می توانید امنیت را افزایش دهید. CloudFront به طور خودکار در برابر حملات DDoS در هر دو سطح شبکه و برنامه دفاع می کند. این امر از طریق روش‌های مختلفی از جمله فیلتر کردن ترافیک، کاهش ترافیک و تغییر مسیر ترافیک به دست می‌آید. علاوه بر این، CloudFront از زیرساخت شبکه جهانی آمازون برای ارائه یک لایه حفاظتی اضافی در لبه شبکه استفاده می کند. همچنین محتوا را از طریق یک شبکه جهانی از مراکز داده به نام مکان‌های لبه ارائه می‌کند. هنگامی که کاربر محتوای ارائه شده با CloudFront را درخواست می کند، درخواست به محل لبه با کمترین تأخیر هدایت می شود و عملکرد مطلوب را تضمین می کند. با این حال، توجه به این نکته مهم است که استفاده از CloudFront برای این نسخه نمایشی اختیاری است.
نتیجه گیری
در این نمایش، ما از خدمات مختلف AWS استفاده کردیم و چندین لایه امنیتی را برای پیروی از رویکرد دفاعی در عمق پیاده‌سازی کردیم. این رویکرد معمولاً برای محافظت از زیرساخت های Cloud استفاده می شود. اگر مهاجمان بخواهند زیرساخت های ما را به خطر بیاندازند، با اقدامات امنیتی متعددی مواجه خواهند شد. ما گروه های امنیتی را برای نمونه های EC2 خود و یک گروه امنیتی اضافی برای Application Load Balancer به کار گرفته ایم. Application Load Balancer ما به حفاظت DDoS و فایروال برنامه وب برای محافظت در برابر حملات مبتنی بر وب مجهز شده است. علاوه بر این، ما دامنه خود را با یک گواهی SSL ایمن کرده ایم و ترافیک را فقط به HTTPS در NACL خود محدود کرده ایم.
اگر این داستان را دوست دارید، دست بزنید و من را دنبال کنید.
وب سایت من را بررسی کنید، اطلاعات اساسی در مورد من به دست خواهید آورد: ahmedsrebrenica.com.
