ღრუბლოვანი უსაფრთხოების რჩევები მხოლოდ მაშინ არის სასარგებლო, როდესაც ისინი თავდამსხმელების მიერ გამოყენებული რეალური ხარვეზების მოგვარებას ემსახურება: საჯარო S3 ბაკეტი, რომელსაც არავინ ამჩნევს, CI მორბენალი wildcard-ით. AWS ნებართვები, გაჟონილი საიდუმლო აწყობის ჟურნალში ან მავნე დამოკიდებულება, რომელიც ჩუმად დაინსტალირდა pipeline გაშვება. ღრუბლოვანი უსაფრთხოების ინციდენტების უმეტესობა უცნობი საფრთხეებით არ არის გამოწვეული. ისინი გამოწვეულია ცნობილი სისუსტეებით, რომლებიც არასდროს ყოფილა აღსრულებული, პრიორიტეტული ან გამოსწორებული.
ეს სახელმძღვანელო მოიცავს ღრუბლოვანი უსაფრთხოების 20 პრაქტიკულ რჩევას, რომლებიც ორგანიზებულია შემდეგი ფენების მიხედვით: იდენტობა, მონაცემები, ინფრასტრუქტურა, პროგრამული უზრუნველყოფის მიწოდების ჯაჭვი, CI/CD pipelines, აღმოჩენა და ინციდენტებზე რეაგირება. იქნება ეს ერთი ღრუბლოვანი ანგარიშის გაძლიერება თუ მრავალგუნდიანი ანგარიშის უზრუნველყოფა DevSecOps pipeline, ეს კონტროლი ხელს უწყობს რეალურად მომხდარი დარღვევების თავიდან აცილებას.
რატომ ვერ ხერხდება ღრუბლოვანი უსაფრთხოება ამდენი რჩევის მიუხედავად
ღრუბლოვანი უსაფრთხოება არის კონტროლის, პოლიტიკისა და ინსტრუმენტების ერთობლიობა, რომელიც იცავს მონაცემებს, აპლიკაციებსა და ღრუბლოვან გარემოში მომუშავე ინფრასტრუქტურას. ის მოიცავს იდენტობას, ქსელს, მონაცემებს, აპლიკაციის კოდს, დამოკიდებულებებს, ინფრასტრუქტურის კონფიგურაციას და აწყობას. pipelines.
მიზეზი, რის გამოც ის წარუმატებელია, თუნდაც გამოცდილი გუნდებისთვის, ცოდნის ნაკლებობა არ არის. ეს სამი სტრუქტურული პრობლემაა:
- სიჩქარე vs. უსაფრთხოება. Pipelineსწრაფად მოძრაობენ. კონტროლის ის საშუალებები, რომლებიც ხახუნს მატებს, გამორთულია. გუნდები, რომლებიც სწორად ახორციელებენ ღრუბლოვან უსაფრთხოებას, არ ამატებენ კარიბჭეებს, ისინი აღსრულებას პირდაპირ სამუშაო პროცესში ავტომატიზირებენ.
- ხელსაწყოების ფრაგმენტაცია. საიდუმლოებების სკანირება ერთ ინსტრუმენტში, SCA სხვაში, IaC მესამედში. ერთიანი შეხედულების არარსებობა ნიშნავს, რომ დაფარვის ფენებს შორის ხარვეზებია და დასკვნები არასდროს კორელაციაშია რეალურ რისკთან.
- ფხიზელი დაღლილობა. სკანერები, რომლებიც დღეში ასობით CVE-ს ავლენენ, ინჟინრებს ასწავლიან, რომ უგულებელყონ აღმოჩენები, მათ შორის კრიტიკული აღმოჩენები. პრიორიტეტების მინიჭება არჩევითი არ არის; ეს არის ის, რაც განსაზღვრავს, რეალურად მუშაობს თუ არა უსაფრთხოება.
ქვემოთ მოცემული ღრუბლოვანი უსაფრთხოების რჩევები შექმნილია ამ ხარვეზების პრაქტიკული გზით შესავსებად. ღრუბლოვანი უსაფრთხოების მხოლოდ გაშვების დროს არსებულ პრობლემად მიჩნევის ნაცვლად, ისინი მოიცავს კოდიდან ღრუბელში მიწოდების სრულ გზას.
20 რჩევა ღრუბლოვანი უსაფრთხოების შესახებ:
იდენტობისა და წვდომის მართვის ღრუბლოვანი უსაფრთხოების რჩევები
1. ჩართეთ მრავალფაქტორიანი ავთენტიფიკაცია ყველგან
MFA ღრუბლოვანი უსაფრთხოების სფეროში ყველაზე მაღალი ROI-ს მქონე ერთადერთ კონტროლად რჩება. ის პირდაპირ აჩერებს ავტორიზაციის ქურდობის შეტევებს და თავდამსხმელებმა ეს იციან. ნებისმიერი ანგარიში, რომელსაც MFA არ გააჩნია, სუსტი სამიზნეა.
MFA-ს აღსრულება თქვენს ღრუბლოვან გარემოში არსებული ყველა ადამიანის იდენტობისთვის: დეველოპერის ანგარიშები, ადმინისტრატორის კონსოლები, ღრუბლოვანი პროვაიდერის პორტალები, CI/CD dashboardს. პრივილეგირებული ანგარიშებისთვის გამოიყენეთ ფიშინგისადმი მდგრადი MFA (აპარატურის გასაღებები, პაროლის გასაღებები). აუთენტიფიკატორის აპლიკაციის მეშვეობით დროზე დაფუძნებული კოდები მინიმალური მოთხოვნაა.
2. მინიმალური პრივილეგიის გამოყენება, განსაკუთრებით არაადამიანური იდენტობების მიმართ
მინიმალური პრივილეგიის პრინციპი კარგად არის გასაგები ადამიანებისთვის. ის ნაწილი, რომელსაც გუნდები მუდმივად გამოტოვებენ, არის არაადამიანური იდენტობები: CI/CD სერვისის ანგარიშები, ლამბდა ფუნქციები, კონტეინერის სამუშაო დატვირთვები, GitHub Actions-ის მორბენლები.
ეს იდენტობები აგროვებენ wildcard ნებართვებს, რადგან ისინი ერთხელ არის კონფიგურირებული და აღარასდროს გამოიყენება ხელახლა. ისინი ასევე ზუსტად ისაა, რასაც თავდამსხმელები ცდილობენ მიწოდების ჯაჭვის შეტევების დროს, რადგან მათ აქვთ წვდომა საიდუმლოებებზე, საცავებზე, წარმოების რესურსებსა და შემდგომ სისტემებზე.
სერვისის ანგარიშის ნებართვების კვარტალური აუდიტი. წაშალეთ ყველაფერი, რაც 90 დღის განმავლობაში არ გამოუყენებიათ.
3. ხანგრძლივი მოქმედების სერთიფიკატების ხანმოკლე მოქმედების ტოკენებით ჩანაცვლება
სტატიკური API გასაღებები და ხანგრძლივი მოქმედების ტოკენები ღრუბლოვანი უსაფრთხოების დარღვევების ერთ-ერთი ყველაზე გავრცელებული მიზეზია. ისინი... commitსაცავებში გადავიდა, CI ჟურნალებში გაჟონა, Slack-ში დაკოპირდა და დავიწყებას მიეცა. .ენვ ფაილები, შემდეგ კი ძალაში რჩება თვეების ან წლების განმავლობაში.
შეძლებისდაგვარად, შეცვალეთ ისინი ხანმოკლე სერთიფიკატებით: AWS STS-ის როლის აღება, GCP სამუშაო დატვირთვის იდენტიფიკაციის ფედერაცია, GitHub-ის მოქმედებები OIDCროდესაც სტატიკური ავტორიზაციის მონაცემები გარდაუვალია, შეინახეთ ისინი საიდუმლოებების მენეჯერში (Vault, AWS Secrets Manager, Azure Key Vault) და ავტომატურად შეცვალეთ ისინი.
4. ამაღლებული პრივილეგიებისთვის დროული წვდომის დანერგვა
მუდმივი ადმინისტრატორის წვდომა მუდმივი რისკია. მუდმივი ამაღლებული ნებართვები ნიშნავს, რომ ერთი კომპრომეტირებული იდენტობა საკმარისია წარმოებაზე გადასასვლელად.
JIT წვდომის სისტემები (AWS IAM Identity Center, GCP Privileged Access Manager, Okta Access Requests) მოთხოვნისამებრ, დროში შეზღუდული და სრული აუდიტის ჟურნალებით გაძლიერებულ წვდომას ანიჭებენ. დეველოპერები იღებენ იმას, რაც სჭირდებათ, როცა ეს სჭირდებათ. თავდამსხმელები ვერ პოულობენ მუდმივ სამიზნეს.
5. ნულოვანი ნდობის აღსრულება სერვისებს შორის კომუნიკაციაში
ტრადიციული პერიმეტრის მოდელები ვარაუდობენ, რომ ქსელში ყველაფერი სანდოა. მიკროსერვისებით, კონტეინერებითა და დინამიური სამუშაო დატვირთვით აღჭურვილი ღრუბლოვანი გარემო ამ ვარაუდს სახიფათოს ხდის.
ნულოვანი ნდობა ნიშნავს, რომ ყველა მოთხოვნა ავთენტიფიცირებული და ავტორიზებულია, მიუხედავად იმისა, თუ საიდან მოდის იგი. დანერგეთ სერვისიდან სერვისამდე ავთენტიფიკაცია (mTLS, სერვისის mesh იდენტურობა), აღასრულეთ ქსელის პოლიტიკა სამუშაო დატვირთვის დონეზე და შიდა ტრაფიკი ნაგულისხმევად არასანდოდ მიიჩნიეთ.
მონაცემთა დაცვის ღრუბლოვანი უსაფრთხოების რჩევები
6. ყველაფრის დაშიფვრა, მათ შორის შიდა ტრაფიკის
დაშიფვრა უმოქმედობის დროს (AES-256, მართული KMS) ახლა არის standard ვარჯიში. გუნდების უმეტესობას შორის არსებული ხარვეზია შიდა ტრაფიკის დაშიფვრა ტრანზიტის დროს.
მიკროსერვისებისა და კონტეინერ-კონტეინერ კომუნიკაციის მქონე VPC-ში, „შიგნით“ დარჩენილი ტრაფიკი თავისთავად უსაფრთხო არ არის. შიდა სერვისის კომუნიკაციისთვის დანერგეთ ურთიერთდახმარების TLS (mTLS). ამის ავტომატურად აღსასრულებლად გამოიყენეთ სერვისის ბადე (Istio, Linkerd) ან ნულოვანი ნდობის ქსელური ფენა, იმის ნაცვლად, რომ თითოეულ გუნდს დაეყრდნოთ მისი სწორად კონფიგურაციისთვის.
7. გამოავლინე და გამოასწორე გამჟღავნებული საიდუმლოებები მათ გავრცელებამდე
საიდუმლო commitრეპოზიტორში გადაცემული ინფორმაცია საიდუმლოდ არ რჩება. GitHub საჯარო რეპოებს წამებში ინდექსირებს. შიდა რეპოები არ არის დაზღვეული, როგორც კი საიდუმლო git-ის ისტორიაში მოხვდება, მასზე წვდომა ნებისმიერი პირისთვის ხდება, ახლა თუ მომავალში.
პრევენციის ფენებს მნიშვნელობა აქვს (pre-commit hooks, IDE დანამატები), მაგრამ საკმარისი არ არის. თქვენ გჭირდებათ უწყვეტი სკანირება ყველა საცავში, მათ შორის ისტორიულში. commits, CI/CD ჟურნალები, IaC ფაილები და კონტეინერის სურათები. საიდუმლოს აღმოჩენისას, რეაგირება დაუყოვნებლივი უნდა იყოს: გაუქმება, როტაცია და შეფასება, მოხდა თუ არა მასზე წვდომა გამჟღავნებასა და აღმოჩენას შორის პერიოდში.
8. მონაცემების კლასიფიკაცია და კონტროლის გამოყენება მგრძნობელობის მიხედვით
თქვენს ღრუბლოვან გარემოში არსებული ყველა მონაცემი ერთნაირი რისკის შემცველი არ არის, თუ გამჟღავნდება. ყველაფრის ერთნაირად მოპყრობა ნიშნავს დაბალი რისკის მქონე მონაცემებში კონტროლის ზედმეტად ინვესტირებას და რეალურად მნიშვნელოვანი მონაცემების არასაკმარის დაცვას.
მონაცემების კლასიფიკაცია მგრძნობელობის მიხედვით (საჯარო, შიდა, კონფიდენციალური, შეზღუდული). წვდომის კონტროლისა და დაშიფვრის გამოყენება. standardდა აუდიტის ჟურნალირების მოთხოვნები თითოეული დონისთვის. კლასიფიკაციის ავტომატიზაცია, სადაც შესაძლებელია, ხელით მონიშვნა არ მასშტაბირდება.
ინფრასტრუქტურისა და კონფიგურაციის უსაფრთხოება
9. სკანირება IaC ყოველ Commit, არა მხოლოდ განლაგებამდე
ინფრასტრუქტურა, როგორც კოდი, არის ის ადგილი, სადაც არასწორი კონფიგურაციები იქმნება და არა წარმოებაში. საჯარო S3 ბაკეტი, ღია უსაფრთხოების ჯგუფი ან IAM როლი *:* ნებართვები შემთხვევით არ ჩნდება. ის იწყება როგორც ხაზი Terraform ფაილში ან Kubernetes-ის მანიფესტში, რომელიც არავის შეუნიშნავს.
IaC სკანირება უნდა შესრულდეს ყოველ pull requestკოდის განხილვის სამუშაო პროცესში აღმოჩენილი დასკვნებით. სკანირება გაუკეთეთ Terraform-ს, Kubernetes-ის მანიფესტებს, CloudFormation-ს, Helm-ის დიაგრამებს, Dockerfiles-ს და CI/CD კონფიგურაციები.
ქსიგენი IaC Security სკანირებს ყველა მხარდაჭერილ ფორმატს ყველა მოწყობილობაზე commit, დასკვნებს კონკრეტულ რესურსებთან აკავშირებს და ინტეგრირდება თქვენს PR სამუშაო პროცესთან, რათა დეველოპერებმა უკუკავშირი მიიღონ იქ, სადაც მუშაობენ და არა ცალკე. dashboard ისინი არასდროს იხსნებიან. დაიწყეთ უფასო საცდელი პერიოდი →
10. უსაფრთხოების პოლიტიკის კოდად აღქმა
უსაფრთხოების ხელით განხილვები არ მასშტაბირდება. პოლიტიკა, როგორც კოდი, მასშტაბირდება.
უსაფრთხოების წესების ვერსიირებული, ტესტირებადი კოდის სახით გამოსახატავად გამოიყენეთ ისეთი ინსტრუმენტები, როგორიცაა OPA (ღია პოლიტიკის აგენტი) ან Kyverno. აღასრულეთ ისინი pipeline დონე, ასე რომ Kubernetes-ის განლაგება პრივილეგირებული: მართალია ან root-ის სახელით გაშვებული კონტეინერი ავტომატურად, ყოველ ჯერზე ვერ ახერხებს ბილდინგი. როდესაც პოლიტიკა კოდშია, ისინი განიხილება და გაუმჯობესდება ნებისმიერი საინჟინრო არტეფაქტის მსგავსად. როდესაც ისინი დოკუმენტაციაშია, ისინი გადაიხრებიან.
11. უსაფრთხო კონფიგურაციის საბაზისო ხაზების აღსრულება და დრიფტის მონიტორინგი
ნაგულისხმევი კონფიგურაციები ოპტიმიზირებულია მოხერხებულობისთვის და არა უსაფრთხოებისთვის. ღრუბლოვანი სერვისები, კონტეინერის გაშვების დრო და მართული Kubernetes კლასტერები აღჭურვილია მარტივი გამოსაყენებელი და ექსპლუატაციის მქონე პარამეტრებით.
დასაწყისიდან CIS თქვენი ღრუბლოვანი პროვაიდერის, კონტეინერის გაშვების დროისა და ოპერაციული სისტემის საორიენტაციო მაჩვენებლები. კოდირეთ ისინი პოლიტიკის კოდის სახით, რათა ავტომატურად ამოქმედდეს. მუდმივად აკონტროლეთ ცვლილებები, გასულ კვირას თავსებადი კონფიგურაცია შესაძლოა დღეს არ იყოს თავსებადი ზეწოლის ქვეშ განხორციელებული სწრაფი ცვლილების შემდეგ.
12. სეგმენტური ქსელები და გვერდითი მოძრაობის შეზღუდვა
ბრტყელი ქსელის არქიტექტურა ნიშნავს, რომ როგორც კი თავდამსხმელი ერთ სამუშაო დატვირთვას დააზიანებს, მას შეუძლია ყველა დანარჩენ სამუშაო დატვირთვაზე წვდომა. ქსელის სეგმენტაცია შეიცავს აფეთქების რადიუსს.
გამოიყენეთ VPC-ები, ქვექსელები და უსაფრთხოების ჯგუფები ფუნქციონალურობისა და მგრძნობელობის მიხედვით იზოლაციის ზონების შესაქმნელად. შეზღუდეთ აღმოსავლეთ-დასავლეთის ტრაფიკი სერვისებს შორის მხოლოდ საჭიროებით. დანერგეთ გასასვლელი ფილტრაცია, კომპრომეტირებული სამუშაო დატვირთვების უმეტესობა თავდამსხმელის მიერ კონტროლირებად სერვერს უნდა მიაღწიოს და გასასვლელი კონტროლი ამის აღმოსაჩენად ან თავიდან ასაცილებლად ერთ-ერთი საუკეთესო შესაძლებლობაა.
პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის ღრუბლოვანი უსაფრთხოების რჩევები
ღრუბლოვანი უსაფრთხოების ზოგიერთი უმნიშვნელოვანესი რჩევა აღარ იწყება ღრუბლოვანი პროვაიდერის კონსოლში. ისინი უფრო ადრე, პროგრამული უზრუნველყოფის მიწოდების ჯაჭვში იწყება. დამოკიდებულებები, CI/CD სამუშაო პროცესები, საიდუმლოებები, შექმნის სკრიპტები და არტეფაქტები - ყველაფერი ეს შეიძლება ღრუბლოვანი რისკის შემცველი იყოს განლაგებამდე.
13. შეამოწმეთ ყველა დამოკიდებულება, სანამ ის თქვენს ბილდში შევა
ღია კოდის პაკეტები თანამედროვე მიწოდების ჯაჭვის შეტევებში ყველაზე გავრცელებული საწყისი წვდომის ვექტორია. 2024 წლის Shai-Hulud კამპანიამ 830+ npm პაკეტი დააზიანა. XZ Utils-ის უკანა კარმა თითქმის დააზიანა SSH ავთენტიფიკაცია მილიონობით Linux სისტემაში. ორივე შემთხვევაში, მავნე კოდი ჩვეულებრივი დამოკიდებულების ინსტალაციის პროცესით შემოვიდა.
ძირითადი SCA (პროგრამული უზრუნველყოფის შემადგენლობის ანალიზი), CVE სიების ნედლი ვერსია საკმარისი არ არის. რა გჭირდებათ სინამდვილეში:
- ხელმისაწვდომობის ანალიზითქვენს კოდში ნამდვილად გამოძახებულია დაუცველი ფუნქცია?
- მავნე პროგრამების გამოვლენა: ავლენს თუ არა ეს პაკეტი მავნე ქცევას, დაბინდულ სკრიპტებს, მოულოდნელ ქსელურ ზარებს, სასიცოცხლო ციკლს? hooks რომლებიც გარე გაშვების დროს აინსტალირებენ?
- EPSS ქულების მინიჭებარა არის ალბათობა, რომ ეს CVE აქტიურად იქნას გამოყენებული ამჟამად, არა მხოლოდ თეორიულად?
14. ჩაკეტვა CI/CD Pipelines
CI/CD სისტემებს აქვთ წვდომა საიდუმლოებებზე, ღრუბლოვან სერთიფიკატებსა და საწარმოო გარემოზე. ისინი ასევე, როგორც წესი, ნაკლებად გამაგრებულები არიან, ვიდრე ის საწარმოო სისტემები, რომლებშიც ისინი ათავსებენ.
აღსასრულებელი კონტროლი:
- კოდის ნებისმიერი ცვლილებისთვის საჭიროა გადახედვა pipeline კონფიგურაციის ფაილები (.github/სამუშაო პროცესები/, ჯენკინსფაილიდა ა.შ.)
- თვითჰოსტირებული მორბენლების შეზღუდვა დამტკიცებულ საცავებში, გადაუმოწმებელი მორბენლის წვდომა ავტორიზაციის ქურდობის პირდაპირი გზაა.
- არასოდეს გადასცეთ საიდუმლოებები ტექსტურ გარემოს ცვლადებად; გამოიყენეთ საიდუმლოებების მენეჯერის ინტეგრაცია.
- აუდიტი pipeline მოულოდნელი ბრძანებების, უჩვეულო ქსელური ზარების ან მოულოდნელ საათებში შესრულების ჟურნალები
ქსიგენი CI/CD უსაფრთხოება ახორციელებს guardrails პირდაპირ თქვენს pipeline , სახიფათო აწყობის დაბლოკვა, ინექციური სამუშაო პროცესების აღმოჩენა და უზრუნველყოფა pipeline პატიოსნება ყველა ეტაპზე. დაჯავშნეთ დემო ვერსია →
15. კონსტრუქციის მთლიანობის დადასტურება და არტეფაქტების ხელმოწერა
თუ თავდამსხმელს შეუძლია კოდის შეყვანა შექმნის სკრიპტში, არტეფაქტის შეცვლა კომპილაციის შემდეგ ან CI მორბენლის კომპრომეტირება, ის ფლობს თქვენი პროგრამული უზრუნველყოფის მიწოდების ჯაჭვს, მიუხედავად იმისა, თუ რამდენად სუფთაა თქვენი საწყისი კოდი.
აწყობის მთლიანობის კონტროლის აღსრულება:
- ყველა დამოკიდებულების ვერსია და საბაზისო სურათი დააფიქსირეთ ზუსტ დაიჯესტებში და არა თეგებში
- განათავსებამდე ხელი მოაწერეთ კონსტრუქციის არტეფაქტებს და გადაამოწმეთ ხელმოწერები
- მოულოდნელი ცვლილებების მონიტორინგი CI/CD სამუშაო პროცესის ფაილები, ინექციური სამუშაო პროცესები Shai-Hulud-ის მსგავსი შეტევების მთავარი ინდიკატორი იყო.
- SLSA-ს ატესტაციების დანერგვა კრიპტოგრაფიულად იმის დასამტკიცებლად, თუ რა შეიქმნა, რა წყაროდან და რით. pipeline
საფრთხის აღმოჩენა და ინციდენტებზე რეაგირება
16. ლოგირების ცენტრალიზაცია და ხილვადობის გაზრდა მთელ სტეკზე
რასაც ვერ ხედავ, იმას ვერ აღმოაჩენ. ღრუბლოვანი უსაფრთხოების მონიტორინგის უმეტესობა ფოკუსირებულია გაშვების დროზე, CloudTrail-ზე, VPC ნაკადის ჟურნალებსა და GuardDuty-ზე. ეს აუცილებელია, მაგრამ არასაკმარისი.
Shai-Hulud-ისა და SolarWinds-ის მსგავსი შეტევები ნაწილობრივ წარმატებული იყო, რადგან კომპრომისი აწყობის დროს მოხდა. pipelineდიდი ხნით ადრე, სანამ რაიმე წარმოების მონიტორინგს მიაღწევდა. სრული ხილვადობა მოითხოვს დაფარვას საწყისი კოდის ცვლილებების, აწყობისა და არტეფაქტების ფენების, ღრუბლოვანი გაშვების დროისა და API აქტივობის შესახებ.
17. დასკვნების პრიორიტეტულობა ექსპლუატაციის მიხედვით და არა მხოლოდ სიმძიმის მიხედვით
კვირაში 500 აღმოჩენის გენერატორი გუნდებს ასწავლის, რომ უგულებელყონ აღმოჩენები, მათ შორის კრიტიკული აღმოჩენები. პრიორიტეტების განსაზღვრა არის ის, რაც განასხვავებს მოქმედ უსაფრთხოების პროგრამებს ქაღალდზე არსებული პროგრამებისგან.
ეფექტური პრიორიტეტიზაცია აერთიანებს: ხელმისაწვდომობას (ნამდვილად შესრულებულია თუ არა დაუცველი კოდი?), ექსპოზიციას (ინტერნეტთან დაკავშირებულია თუ არა სერვისი?), EPSS ქულას (აქტიური ექსპლუატაციის ალბათობა) და ბიზნეს კონტექსტს (წარმოების vs. დეველოპერული გარემო).
Xygeni ASPM ყველა აღმოჩენას აერთიანებს SAST, SCA, IaC, საიდუმლოებები და pipeline security ერთიან რისკების ხედვაში, კონტექსტური პრიორიტეტულობით, რომელიც თქვენს გუნდს ზუსტად ეუბნება, თუ რა უნდა გამოასწოროს პირველ რიგში. დაჯავშნეთ დემო ვერსია →
18. ქცევითი საბაზისო ხაზების დადგენა და გადახრების შემთხვევაში გაფრთხილება
ცნობილი-ცუდი ხელმოწერები ცნობილ საფრთხეებს აფიქსირებს. ქცევითი ანომალიების აღმოჩენა კი უცნობ საფრთხეებს, ნულოვან დღეებს, შეტევის ახალ ნიმუშებს, ინსაიდერულ საფრთხეებს აფიქსირებს.
თქვენი CI/CD კონკრეტულად გარემოში, დაადგინეთ საბაზისო ხაზები ტიპიური აწყობის ხანგრძლივობისთვის, პაკეტების ნორმალური ინსტალაციის ნიმუშებისთვის, აწყობის დროს მოსალოდნელი ქსელური დანიშნულების ადგილებისთვის და standard საიდუმლოებებზე წვდომის შაბლონები. ამ საბაზისო ხაზებიდან გადახრები თქვენი ყველაზე ადრეული გამაფრთხილებელი სიგნალია და ის ფენა, რომელშიც გუნდების უმეტესობას ნულოვანი ხილვადობა აქვს.
19. ღრუბლოვანი ინციდენტების სცენარებისთვის Runbook-ების განსაზღვრა
ინციდენტებზე რეაგირების ზოგადი გეგმები არ ითვალისწინებს ღრუბელზე სპეციფიკურ სცენარებს: კომპრომეტირებული პაკეტი, რომელიც უკვე დაინსტალირებულია 40 სერვისზე, CI გამშვები, რომლის ავტორიზაციის მონაცემებიც მოიპარა მავნე წინასწარი ინსტალაციის სკრიპტმა, აწყობის არტეფაქტი, რომელიც შესაძლოა ბოლო 72 საათის განმავლობაში გაყალბებულიყო.
შექმენით სპეციფიკური საკონტროლო წიგნები შემდეგი შემთხვევებისთვის: კომპრომეტირებული დამოკიდებულება, pipeline ავტორიზაციის ქურდობა, არასწორი კონფიგურაციით გამოწვეული მონაცემების ექსპოზიცია და მავნე CI სამუშაო პროცესის ინექცია. თითოეულ Runbook-ში უნდა იყოს განსაზღვრული, თუ ვის ეკუთვნის პასუხი, რა უნდა გაუქმდეს დაუყოვნებლივ და რა სახის ექსპერტიზაა საჭირო აფეთქების რადიუსის დასადგენად.
20. გაუშვით მაგიდის სავარჯიშოcises, წელიწადში მინიმუმ ორჯერ
დაუტესტავი runbook ჰიპოთეზაა. მაგიდის სავარჯიშოcisგამოავლინეთ თქვენი რეაგირების გეგმის ხარვეზები თავდამსხმელის წინაშე. მიზანი არ არის სახელმძღვანელოს სრულყოფილად დაცვა, არამედ იმის აღმოჩენა, თუ რა აკლია.
შეასრულეთ მინიმუმ ორი ვარჯიშიcisწელიწადში, სხვადასხვა სცენარის ტიპის სიმულირებით: მიწოდების ჯაჭვის კომპრომეტირება, არასწორი კონფიგურაციით გამოწვეული მონაცემთა დარღვევა, კომპრომეტირებული CI გამშვები. ჩართეთ გუნდები, რომლებიც რეალურად მოახდენენ რეაგირებას, უსაფრთხოების, DevOps-ის და მორიგე დეველოპერები.
ღრუბლოვანი უსაფრთხოების რჩევების საკონტროლო სია: მოკლე მითითება
| Layer | გასაღების კონტროლი |
|---|---|
| პირადობის | MFA ყველგან, მინიმალური პრივილეგიები, ხანმოკლე სერთიფიკატები, JIT წვდომა |
| თარიღი | დაშიფვრა როგორც უმოქმედო, ასევე ტრანზიტის დროს, საიდუმლოებების სკანირება და ავტომატური გაუქმება, მონაცემთა კლასიფიკაცია |
| ინფრასტრუქტურის | IaC სკანირება ჩართულია commit, პოლიტიკა, როგორც კოდი, CIS საბაზისო აღსრულება, ქსელის სეგმენტაცია |
| მიწოდების ქსელი | SCA ხელმისაწვდომობითა და მავნე პროგრამების აღმოჩენით, CI/CD გამკვრივება, მთლიანობის აშენება და SLSA |
| გამოვლენა | ცენტრალიზებული ჟურნალირება, EPSS-ზე დაფუძნებული პრიორიტეტიზაცია, ქცევითი ანომალიების აღმოჩენა |
| რეაგირების | ღრუბლოვანი პროგრამებისთვის განკუთვნილი Runbooks, მაგიდის სავარჯიშოებიcises, დოკუმენტირებული აფეთქების რადიუსის შეფასება |
როგორ ეხმარება Xygeni ღრუბლოვანი უსაფრთხოების რჩევების გამოყენებას მთელ სტეკზე
ღრუბლოვანი უსაფრთხოების რჩევები მხოლოდ მაშინ მუშაობს, როდესაც გუნდებს შეუძლიათ მათი თანმიმდევრულად აღსრულება პროგრამული უზრუნველყოფის მიწოდების სრული სასიცოცხლო ციკლის განმავლობაში. ხელსაწყოების უმეტესობა მოიცავს ერთ ფენას: გაშვების დროს, კოდს, დამოკიდებულებებს, საიდუმლოებებს ან CI/CDმაგრამ რეალური შეტევები სხვადასხვა ფენას მოიცავს.
Xygeni აკავშირებს ამ ფენებს ინტეგრირებული აღმოჩენის, პრიორიტეტიზაციისა და გამოსწორების გზით, პირველი git push-დან წარმოებამდე.
| Layer | Xygeni-ის შესაძლებლობა | რას უშლის ხელს |
|---|---|---|
| კოდის | SAST + ხელოვნური ინტელექტის აღდგენა | ინექცია, ავტორიზაციის შეცდომები, დაუცველი დიზაინი |
| დამოკიდებულება | SCA + მავნე პროგრამების აღმოჩენა + EPSS | მიწოდების ჯაჭვის კომპრომეტირება, დაუცველი პაკეტები |
| Secrets | საიდუმლოებები უსაფრთხოება + ავტომატური გაუქმება | სერთიფიკატის ექსპოზიცია, ხანგრძლივი ტოკენის რისკი |
| IaC & კონფიგურაცია | IaC Security | არასწორი კონფიგურაციები წარმოებამდე |
| CI/CD Pipeline | CI/CD უსაფრთხოება + ანომალიების აღმოჩენა | Pipeline ინექცია, მორბენლის კომპრომისი |
| არტეფაქტების შექმნა | Build Security + SLSA provenance | გაყალბებული არტეფაქტები, ხელმოუწერელი რელიზები |
| რისკის პოზიცია | ASPM | ერთიანი ხედი, ჯვარედინი ფენის პრიორიტეტიზაცია |
შედეგად, უსაფრთხოების ჯგუფები ხმაურის ნაცვლად სიგნალს იღებენ. დეველოპერები უკუკავშირს იქ იღებენ, სადაც მუშაობენ და არა ცალკე ინსტრუმენტში, რომელსაც არასდროს ხსნიან. უსაფრთხოება კი მიწოდების პროცესის ნაწილი ხდება და არა კარიბჭე, რომელიც მას ანელებს.
საბოლოო ფიქრები
ღრუბლოვანი უსაფრთხოების რჩევების ჩამოთვლა მარტივია, მაგრამ მათი აღსრულება უფრო რთულია. გუნდები, რომლებიც რეალურ ღრუბლოვან რისკებს ამცირებენ, არ ეყრდნობიან ხელით მიმოხილვებს, გაფანტულ ინსტრუმენტებს ან მხოლოდ სიმძიმის მიხედვით პრიორიტეტულობის მინიჭებას. ამის ნაცვლად, ისინი ავტომატიზირებენ უსაფრთხოების კონტროლს შიდა სისტემებში. pipelines, პრიორიტეტი მიანიჭეთ ექსპლუატაციის მიხედვით და სრული პროგრამული უზრუნველყოფის მიწოდების ჯაჭვი ღრუბლოვანი შეტევის ზედაპირის ნაწილად მიიჩნიეთ.
ეს ნიშნავს არა მხოლოდ გაშვების დროს ინფრასტრუქტურის დაცვას. ეს ნიშნავს საწყისი კოდის, დამოკიდებულებების, საიდუმლოებების დაცვას. IaC, CI/CD სამუშაო პროცესები, არტეფაქტების შექმნა და აპლიკაციის რისკის პოზიცია ერთად.
თუ თქვენი ამჟამინდელი ინსტრუმენტები ამ ფენებს შორის ხარვეზებს ტოვებს, Xygeni დაგეხმარებათ მათ დახურვაში ინტეგრირებული აღმოჩენის, პრიორიტეტიზაციისა და გამოსწორების გზით, კოდიდან ღრუბელამდე მთელ გზაზე.
???? დაიწყეთ თქვენი 7-დღიანი უფასო საცდელი პერიოდი , საკრედიტო ბარათი არ არის საჭირო, სკანირების შედეგები წუთებში
???? წიგნის დემო და ნახეთ, როგორ უკავშირდება Xygeni თქვენს კონკრეტულ ღრუბელს და pipeline setup
ავტორის შესახებ
თანადამფუძნებელი და ტექნიკური დირექტორი
ფატიმა Said სპეციალიზირებულია დეველოპერებისთვის პირველ რიგში განკუთვნილ კონტენტზე AppSec, DevSecOps და software supply chain securityის რთულ უსაფრთხოების სიგნალებს მკაფიო, ქმედით ინსტრუქციებად აქცევს, რაც გუნდებს ეხმარება პრიორიტეტების უფრო სწრაფად განსაზღვრაში, ხმაურის შემცირებასა და კოდის უფრო უსაფრთხოდ გაგზავნაში.
