პირადი RDS EC2-იდან: იგივე VPC, peering თუ სხვა რამ?

დეველოპერის ლეპტოპი პირად RDS ინსტანსს პერსონალის VPN-ის გავლით აღწევს, მაგრამ EC2-ზე მომუშავე აპლიკაცია საერთოდ ვერ უკავშირდება. ეს გატეხილი განლაგება არ არის. ლეპტოპს აქვს გვირაბი, რომელსაც EC2 ინსტანსი არასდროს მემკვიდრეობით იღებს, ხოლო „პირადი“ RDS-ში ნიშნავს, რომ მონაცემთა ბაზას საჯარო ბოლო წერტილი არ აქვს, და არა იმას, რომ ადამიანი VPN მომხმარებლები ერთადერთი დაშვებული გამომძახებლები არიან. აპლიკაციას სჭირდება საკუთარი ავტორიზებული გზა, საკუთარი ურთიერთობა უსაფრთხოების ჯგუფთან და საკუთარი იდენტობა მონაცემთა ბაზაში, და ის თანმიმდევრობა, რომლითაც ამ სამს ირჩევთ, დეპურაციის დიდ ნაწილს ზოგავს. ჯერ მარშრუტი გადაწყვიტეთ, შემდეგ ნებართვები, და შემდეგ გადაამოწმეთ განლაგებული გარემოდან და არა თქვენი მაგიდიდან.

ლეპტოპის VPN აპლიკაციის გზა არ არის

რაც არ უნდა აკეთებდეს პერსონალის VPN ხალხისთვის, ის არაფერს აკეთებს ინსტანსისთვის, თუ ეს ინსტანსი ცხადად არ არის იმავე ქსელური გზის ნაწილი. კერძო ქვექსელში მყოფი EC2 ინსტანსი RDS-ს აღწევს VPC მარშრუტიზაციით, უსაფრთხოების ჯგუფებით და ქსელური ACL-ებით. ის არ მემკვიდრეობით იღებს ადამიანის გვირაბს, ადამიანის სესიას ან ადამიანის სერთიფიკატებს და არც უნდა იღებდეს: უყურადღებო აპლიკაციის კავშირი და პერსონალის დისტანციური წვდომა დამოუკიდებლად უნდა მუშაობდეს.

ეს დამოუკიდებლობა უპირატესობაა. როცა VPN გამორთულია, აპლიკაცია აგრძელებს მუშაობას. როცა აპლიკაცია ცუდად იქცევა, არავინ კარგავს დისტანციურ წვდომას. დიზაინები, რომლებიც ორივეს ერთ გზაში აერთიანებს, ჩვეულებრივ ინციდენტის დროს აღმოჩნდება, ყველაზე ცუდ მომენტში.

გადაწყვეტილება 1: იგივე VPC, პირდაპირი გზა

როცა აპლიკაცია და მონაცემთა ბაზა ერთ VPC-ში არიან პირდაპირი მარშრუტიზაციით და მათ შორის შემოწმების შუამავალი მოწყობილობის გარეშე, გზა მარტივია და უსაფრთხოების ჯგუფის მითითება ყველაზე ძლიერი ხელმისაწვდომი ინსტრუმენტია. მიეცით აპლიკაციას საკუთარი ჯგუფი, შემდეგ დაუშვით მონაცემთა ბაზის პორტი ამ ჯგუფიდან და არა მისამართების დიაპაზონიდან:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

პორტი საილუსტრაციოა და ძრავს უნდა შეესაბამებოდეს. ჯგუფის მითითება ავტორიზებს ტრაფიკს აპლიკაციის ინსტანსებიდან; ის არ აკოპირებს მათ წესებს და არ ქმნის მონაცემთა ბაზის შესვლას. ორი ცალკე პრობლემა, ორი ცალკე გამოსწორება.

შემდეგ შეამოწმეთ გზის დარჩენილი ნაწილი და არ გაჩერდეთ ახლახან დამატებულ წესზე. აპლიკაციის გამავალი პოლიტიკა, მონაცემთა ბაზაზე მიმაგრებული ჯგუფების სრული ნაკრები, ქვექსელის მარშრუტიზაციის ცხრილები და ნებისმიერი ქსელური ACL ყველა უნდა შეთანხმდეს. უსაფრთხოების ჯგუფების წესები მდგომარეობის მქონეა, ხოლო მორგებულ ქსელურ ACL-ს მოთხოვნა და დაბრუნების ტრაფიკი ცალკე წესებში უნდა დაუშვას, დროებითი პორტების ჩათვლით. ახალი ვიწრო მონაცემთა ბაზის წესი ასევე არ აუქმებს ადრე მიმაგრებულ ძველ ფართო ნებართვას.

გადაწყვეტილება 2: სხვა VPC ან სხვა ანგარიში

თუ აპლიკაცია სხვა VPC-შია, ქსელის მფლობელები ირჩევენ მხარდაჭერილ კერძო ურთიერთკავშირს: peering, ტრანზიტული დიზაინი ან გაზიარებული VPC შეთანხმება. მაშინ მარშრუტიზაციის ორივე მიმართულება უნდა არსებობდეს, სახელების გარჩევა RDS ბოლო წერტილისთვის უნდა მუშაობდეს, და წყარო, რომელსაც მონაცემთა ბაზის პოლიტიკა აფასებს, უნდა შეესაბამებოდეს რეალურად ჩამოსულს. ანგარიშების სახელების დამთხვევა ან საერთო დაბილინგებო ურთიერთობა ამათგან არაფერს იძლევა.

უსაფრთხოების ჯგუფის მითითება ის ნაწილია, რომელიც იცვლება. ის მუშაობს კერძო ურთიერთკავშირის რამდენიმე დიზაინში, მაგრამ წყვეტს მუშაობას იმ მომენტში, როცა შუამავალი მოწყობილობა წყაროს გადაწერს ან კავშირს წყვეტს, რადგან მაშინ მონაცემთა ბაზა ხედავს შუამავალს და არა თქვენს აპლიკაციის ჯგუფს. RDS-ის VPC სცენარები ერთი VPC-ის შიგნით წვდომას სხვა შეთანხმებებისგან გამოყოფს და ღირს თქვენი კონკრეტული ტოპოლოგიის მათთან შედარება, სანამ ჩათვლით, რომ წესის სტილი გადადის.

არ გადაწყვიტოთ დაკარგული მარშრუტი მონაცემთა ბაზის საჯაროდ ხელმისაწვდომობით. ეს სხვა მფლობელის მქონე სხვა გამოვლენის გადაწყვეტილებაა და ჩვეულებრივ მას სთავაზობს ის, ვინც შედეგისგან ყველაზე შორს არის.

გადაწყვეტილება 3: რა იდენტობას იღებს მონაცემთა ბაზა

ქსელური წვდომა და მონაცემთა ბაზის აუთენტიფიკაცია ცალკე ფენებია და მათი არევა ყველაზე შეცდომაში შემყვან შეცდომებს ქმნის. ინსტანსის როლი AWS იდენტობაა AWS API-ების გამოსაძახებლად. ის მონაცემთა ბაზის მომხმარებელი არ არის. IAM მონაცემთა ბაზის აუთენტიფიკაცია მხარდაჭერილი ფუნქციაა იქ, სადაც ძრავა და კონფიგურაცია იძლევა საშუალებას, და ის მაინც მონაცემთა ბაზის მომხმარებელზე დაბმაა და არა მისი ჩანაცვლება.

აპლიკაციის კონფიგურაციაში გამოიყენეთ RDS ბოლო წერტილის სახელი და არა ერთი ძიებიდან აღებული მისამართი. Multi-AZ გადართვა ცვლის ამ სახელის უკან არსებულ მისამართს და IP-ზე მიმაგრებული აპლიკაცია ჩავარდება ზუსტად იმ მომენტში, როცა საჭიროა. დატოვეთ ძრავის TLS შემოწმება ჩართული და ნუ გამორთავთ შეცდომის გასაქრობად, რადგან შემოწმების ჩავარდნა რაღაცას გეუბნებათ იმ ბოლო წერტილზე, რომელსაც მიაღწიეთ.

შემდეგ მიეცით მონაცემთა ბაზის ანგარიშს ის მინიმუმი, რაც აპლიკაციას სჭირდება, იმ სქემაში, რომელსაც ის რეალურად იყენებს. ეს სამუშაო მოსაწყენია, ის აუდიტირებადია და სწორედ ეს ნაწილი იკითხება ინციდენტის განხილვისას.

გადაამოწმეთ განლაგებული გარემოდან

ტესტეთ ინსტანსიდან ან დავალებიდან, რომელიც იმავე ჯგუფით, ქვექსელით და როლით მუშაობს. ოთხი ჩავარდნა ლეპტოპიდან მსგავსად გამოიყურება და იქიდან ადვილად გაირჩევა: სახელი, რომელიც არ იხსნება, კავშირი, რომელსაც დრო ეწურება, TLS ვალიდაციის ჩავარდნა და უარყოფილი მონაცემთა ბაზის შესვლა. თითოეული სხვა საზღვარზე მიუთითებს და მონაცემთა ბაზის გამოვლენის შეცვლა მანამ, სანამ იცით რომელი გაქვთ, ვარაუდია.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

თუ კავშირი წარმატებულია ინსტანსიდან და ჩავარდება თქვენი მაგიდიდან, აპლიკაციის გზა რიგზეა და თქვენი წვდომაა გამოსასწორებელი. თუ ის ორივედან ჩავარდება, დაიწყეთ ზემოთ მოცემული ჯგუფის და მარშრუტის შემოწმებებით და არა სერთიფიკატებით. სწორედ ეს ერთი შედარება იცავს ამ ბილეთების მიერ შექმნილი აურზაურის დიდ ნაწილს.