შიდა ALB საჯარო DNS სახელით: ნამდვილად ღიაა?

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

პირველი ნაბიჯი: წაიკითხეთ სქემა, არა IP

სქემის ველი თავად ბალანსირებულის განცხადებაა მისი საზღვრის შესახებ. aws elbv2 describe-load-balancers --names app-internal აბრუნებს Scheme-ს internal ან internet-facing მნიშვნელობით, პლუს მისამართის ტიპი IPv4 ან ორმაგი სტეკისთვის. ინტერნეტისკენ მიმართული ბალანსირებულის მაინც შეუძლია კერძო სამიზნეებზე გადაცემა, ამიტომ კერძო backend მისამართების დანახვა წინა მხარის შესახებ არაფერს ამტკიცებს.

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

მეორე ნაბიჯი: ნახეთ, რაში იხსნება სახელი

ჰკითხეთ VPC-ის გარედან dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com-ით და შენიშნეთ, არიან თუ არა პასუხები 10.0.0.0/8, 172.16.0.0/12 თუ 192.168.0.0/16 დიაპაზონში. კერძო პასუხი საჯარო resolver-ისგან შიდა ბალანსირებულის სახელისთვის მოსალოდნელი ქცევაა; ეს არ არის მტკიცებულება, რომ მისამართი ინტერნეტიდან მარშრუტიზებადია.

გადაწყვიტეთ იგივე სახელი VPC-ის შიგნიდან და შეადარეთ. თუ ორი პასუხი განსხვავდება, თქვენ ხედავთ split-horizon დასახელებას და ეს განსხვავება დიზაინის დეტალია, არა გაჟონვა.

მესამე ნაბიჯი: ჩამოთვალეთ ბილიკები, რომლებსაც შეუძლიათ მისვლა

კერძო მისამართი ხელმისაწვდომია ყველგან, სადაც მარშრუტი და უსაფრთხოების წესია. ჩამოთვალეთ ისინი განზრახ: საიტ-საიტ VPN, კლიენტის VPN, VPC peering, transit gateway-ის მიერთებები, Direct Connect და ნებისმიერი proxy ან bastion VPC-ის შიგნით. ერთი მათგანი განზრახული ბილიკია, დანარჩენი კი ის, რასაც თავდამსხმელი მოძებნიდა.

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

მეოთხე ნაბიჯი: გამოსცადეთ listener და აპლიკაცია ცალ-ცალკე

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

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

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

მეხუთე ნაბიჯი: გადაწყვიტეთ, მნიშვნელოვანია თუ არა თავად სახელი

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

თუ ორგანიზაციას კერძო დასახელების გამოცდილება სურს, კერძო hosted zone-ს შეუძლია alias მოემსახუროს, რომელიც მხოლოდ დაკავშირებული VPC-ების შიგნით გადაწყდება. ეს ცვლის სახელს, რომელსაც მომხმარებლები ხედავენ; ის არ აქცევს მიმწოდებლის მიერ შექმნილ სახელს საიდუმლოდ და არ შლის არცერთ ქსელურ ბილიკს.

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