სტეიჯინგი პროდაქშენი არ არის: მიეცი მას საკუთარი წვდომის საზღვარი
სტეიჯინგის იარლიყი არ წყვეტს, ვინ მიაღწევს აპს ან რას შეეხოს. გამოქვეყნებამდე გადახედე აუდიტორიას, მონაცემებს, სერტიფიკატებს და ადმინის ზედაპირებს.
სტეიჯინგი ტესტურ სისტემას ჰგავს, სანამ არ შეამჩნევ მის გარემოში კოპირებულ პროდაქშენ მონაცემთა ბაზას, ცოცხალ საფოსტო სერტიფიკატს და გადახდის გასაღებს. იმ მომენტში ჩანართის იარლიყი მნიშვნელობას კარგავს და ნამდვილი კითხვაა, რას შეიძლება მიაღწიოს ამ განლაგებამ და ვინ შეიძლება მიაღწიოს მას. წინა კარის VPN ამ კითხვას არ პასუხობს, რადგან ის სისტემაში შესვლის ერთ გზას ზღუდავს და არაფერს ამბობს იმაზე, რა შეიძლება გააკეთოს სისტემამ გასვლისას. დაიწყე აუდიტორიიდან და იმუშავე გარეთკენ.
დაიწყე აუდიტორიიდან და არა URL-იდან
სამი აუდიტორია სამ განსხვავებულ დიზაინს იძლევა. კერძო საინჟინრო გარემოს სჭირდება იდენტობა და მარშრუტი; მომხმარებლის მიღების ტესტს სჭირდება ანგარიშები, რომლებიც მომხმარებლებს წარმოადგენენ; საჯარო დემონსტრაციას სჭირდება განზრახ გამოვლენა საკუთარი კონტროლებით. აუდიტორიის პირველად ჩაწერა ხელს უშლის ჩვეულ დრეიფს, როცა გადახედვის URL ჩუმად ხდება მუდმივი. დანარჩენი ყველაფერი მიმოხილვაში ამ პასუხზეა დამოკიდებული.
თუ ვერავინ დაასახელებს აუდიტორიას, მიიჩნიე ეს პირველ აღმოჩენად და არა დოკუმენტაციის ხარვეზად.
გაიარე წინა კარი და მის უკან არსებული ზედაპირები
გადაწყვიტე სახელები, სანამ მოგცემულ URL-ს ენდობი, შემდეგ კი უშუალოდ ითხოვე ადმინისტრაციული ბილიკები.
dig +short staging.example.com
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/
curl -sS -o /dev/null -w "%{http_code}\n" https://staging.example.com/adminდამატებითი ჩანაწერები ხშირად ავლენს პირდაპირი წარმოშობის მისამართს, რომელიც გვერდს უვლის CDN-ს ან VPN-ის შესასვლელს, რაც განზრახ კონტროლს არასავალდებულოს ხდის. გადამისამართება გეუბნება, სად ფიქრობს აპი, რომ ცხოვრობს, ხოლო მოულოდნელი სქემა ან ჰოსტის სახელი შემდგომ შემოწმებას იმსახურებს. სავარაუდო ადმინ ბილიკის შემოწმებამ უნდა მოგცეს უარი და არა გვერდი. 200 პასუხი აუთენტიფიკაციის გარეშე ადმინისტრაციულ ბილიკზე არის ის აღმოჩენა, რომელსაც მთელი მიმოხილვა ეძებდა.
შეამოწმე, რა შეუძლია გარემოს და არა მხოლოდ რას აჩვენებს
გვერდი, რომელიც შესვლას მოითხოვს, მაინც ბექენდის უფლებამოსილებით იგზავნება. იკითხე, რომელი იდენტობით მუშაობს დატვირთვა, შემდეგ წაიკითხე მასზე მიმაგრებული პოლიტიკები.
aws sts get-caller-identityის გამოძახება აცნობს ანგარიშს და ძირითად სუბიექტს, რომელსაც გარემო რეალურად იყენებს, და ეს არის ყოველი შემდგომი ნებართვის კითხვის საწყისი წერტილი. იქიდან შეამოწმე, შეუძლია თუ არა იდენტობას ფოსტის გაგზავნა, ფულის გადაადგილება, პროდაქშენ საიდუმლოებების წაკითხვა ან პროდაქშენ მონაცემების ჩაწერა. შეცვალე საერთო პროდაქშენ სერტიფიკატები შეზღუდული სტეიჯინგ იდენტობებით და უპირატესობა მიეცი მომწოდებლის sandbox-ებს, სადაც არსებობს. სატესტო ანგარიში, რომელსაც რეალური ბარათის დარიცხვა შეუძლია, პროდაქშენ სისტემაა სხვა ჰოსტის სახელით.
შეინარჩუნე საზღვარი მიმოხილვის დასრულების შემდეგ
გარემო არ იცავს თავს ერთი აუდიტით; მას იცავს საკუთრება, რომელიც პერსონალის ცვლას გადაურჩება. დანიშნე, ვინ აშორებს წვდომას, აბრუნებს სატესტო მონაცემებს და ამუშავებს განლაგებას, და მიეცი გადახედვას ვადა, რომელიც ვიღაცამ უნდა განაახლოს. იზოლაცია მხოლოდ მაშინ ეხმარება, სანამ იზოლირებული რამ მოვლილია. ხელახლა შეამოწმე იგივე ბილიკები შემდეგი გამოშვების შემდეგ, რადგან ფუნქციის დროშა ან ახალი ინტეგრაცია ზუსტად ის გზაა, რომლითაც უარყოფილი მარშრუტი ღია ხდება.
მიიღე დიზაინი დაშვებული სამუშაო ნაკადით და უარყოფილით. თუ ორივე დოკუმენტირებულად იქცევა, საზღვარი არსებობს; თუ მხოლოდ ბედნიერი ბილიკი შემოწმდა, ეს იმედია.