ஜூலை 19, 2019 அன்று, கேபிடல் ஒன் ஒவ்வொரு நவீன நிறுவனமும் அஞ்சும் செய்தியைப் பெற்றது—ஒரு தரவு மீறல் ஏற்பட்டது. இது 106 மில்லியனுக்கும் அதிகமான மக்களை பாதித்தது. 140 அமெரிக்க சமூகப் பாதுகாப்பு எண்கள், ஒரு மில்லியன் கனடிய சமூகப் பாதுகாப்பு எண்கள். 000 வங்கிக் கணக்குகள். விரும்பத்தகாதது, நீங்கள் ஒப்புக்கொள்ளவில்லையா?
துரதிர்ஷ்டவசமாக, ஹேக் ஜூலை 19 அன்று நிகழவில்லை. அது மாறிவிடும், பைஜ் தாம்சன், ஏ.கே. ஒழுங்கற்ற, மார்ச் 22 மற்றும் மார்ச் 23, 2019 க்கு இடையில் அதைச் செய்தார். அது கிட்டத்தட்ட நான்கு மாதங்களுக்கு முன்பு. உண்மையில், வெளிப்புற ஆலோசகர்களின் உதவியால்தான் கேபிடல் ஒன் நிறுவனத்தால் ஏதோ நடந்தது என்பதைக் கண்டறிய முடிந்தது.
ஒரு முன்னாள் அமேசான் ஊழியர் கைது செய்யப்பட்டார் மற்றும் $250 அபராதம் மற்றும் ஐந்து ஆண்டுகள் சிறைத்தண்டனையை எதிர்கொள்கிறார்... ஆனால் இன்னும் நிறைய எதிர்மறைகள் உள்ளன. ஏன்? ஏனெனில் ஹேக்குகளால் பாதிக்கப்பட்ட பல நிறுவனங்கள் சைபர் கிரைம் அதிகரித்து வருவதால், தங்கள் உள்கட்டமைப்பு மற்றும் பயன்பாடுகளை வலுப்படுத்துவதற்கான பொறுப்பை தட்டிக்கழிக்க முயற்சிக்கின்றன.
எப்படியிருந்தாலும், இந்த கதையை நீங்கள் எளிதாக கூகிள் செய்யலாம். நாங்கள் நாடகத்திற்கு செல்ல மாட்டோம், ஆனால் அதைப் பற்றி பேசுவோம் தொழில்நுட்ப விஷயத்தின் பக்கம்.
முதலில், என்ன நடந்தது?
கேபிடல் ஒன்னில் சுமார் 700 S3 வாளிகள் இயங்கின, பைஜ் தாம்சன் அதை நகலெடுத்து எடுத்துச் சென்றார்.
இரண்டாவதாக, இது தவறாக உள்ளமைக்கப்பட்ட S3 பக்கெட் கொள்கையின் மற்றொரு விஷயமா?
இல்லை, இந்த முறை இல்லை. இங்கே அவள் தவறாக உள்ளமைக்கப்பட்ட ஃபயர்வால் கொண்ட சேவையகத்திற்கான அணுகலைப் பெற்று அங்கிருந்து முழு செயல்பாட்டையும் மேற்கொண்டாள்.
காத்திருங்கள், அது எப்படி சாத்தியம்?
சரி, எங்களிடம் அதிக விவரங்கள் இல்லை என்றாலும், சர்வரில் உள்நுழைவதன் மூலம் தொடங்குவோம். இது "தவறாக கட்டமைக்கப்பட்ட ஃபயர்வால்" மூலம் நடந்தது என்று மட்டுமே எங்களிடம் கூறப்பட்டது. எனவே, தவறான பாதுகாப்பு குழு அமைப்புகள் அல்லது இணைய பயன்பாட்டு ஃபயர்வால் (Imperva) அல்லது நெட்வொர்க் ஃபயர்வால் (iptables, ufw, shorewall, முதலியன) உள்ளமைவு போன்ற எளிமையான ஒன்று. கேபிடல் ஒன் மட்டும் தன் குற்றத்தை ஒப்புக்கொண்டு, ஓட்டையை மூடிவிட்டதாகக் கூறியது.
ஃபயர்வால் பாதிப்பை கேபிடல் ஒன் முதலில் கவனிக்கவில்லை, ஆனால் அதை அறிந்தவுடன் விரைவாக செயல்பட்டதாக ஸ்டோன் கூறினார். ஹேக்கர் முக்கிய அடையாளம் காணும் தகவலை பொது களத்தில் விட்டுவிட்டதாகக் கூறப்படும் உண்மையால் இது நிச்சயமாக உதவியது, ஸ்டோன் கூறினார்.
நாங்கள் ஏன் இந்தப் பகுதியை ஆழமாகச் செல்லவில்லை என்று நீங்கள் யோசித்தால், வரையறுக்கப்பட்ட தகவல்களால் மட்டுமே நாங்கள் ஊகிக்க முடியும் என்பதை புரிந்து கொள்ளுங்கள். ஹேக் கேபிடல் ஒன் விட்டுச்சென்ற துளையைச் சார்ந்தது என்பதால் இது அர்த்தமற்றது. மேலும் அவர்கள் எங்களிடம் கூறாத வரை, கேபிடல் ஒன் அவர்களின் சேவையகத்தைத் திறந்து வைத்துள்ள சாத்தியமான வழிகளை பட்டியலிடுவோம், மேலும் இந்த வெவ்வேறு விருப்பங்களில் ஒன்றை யாராவது பயன்படுத்தக்கூடிய சாத்தியமான அனைத்து வழிகளையும் சேர்த்து பட்டியலிடுவோம். இந்த குறைபாடுகள் மற்றும் நுட்பங்கள் பெருமளவில் முட்டாள்தனமான மேற்பார்வைகளிலிருந்து நம்பமுடியாத சிக்கலான வடிவங்கள் வரை இருக்கலாம். சாத்தியக்கூறுகளின் வரம்பைக் கருத்தில் கொண்டு, இது உண்மையான முடிவு இல்லாமல் நீண்ட தொடர்கதையாக மாறும். எனவே, நம்மிடம் உண்மைகள் இருக்கும் பகுதியை பகுப்பாய்வு செய்வதில் கவனம் செலுத்துவோம்.
எனவே முதல் டேக்அவே: உங்கள் ஃபயர்வால்கள் என்ன அனுமதிக்கின்றன என்பதை அறிந்து கொள்ளுங்கள்.
திறக்கப்பட வேண்டியவை மட்டுமே திறக்கப்படுவதை உறுதிசெய்ய ஒரு கொள்கை அல்லது சரியான செயல்முறையை உருவாக்கவும். நீங்கள் பாதுகாப்பு குழுக்கள் அல்லது நெட்வொர்க் ACLகள் போன்ற AWS ஆதாரங்களைப் பயன்படுத்துகிறீர்கள் என்றால், தணிக்கை செய்வதற்கான சரிபார்ப்புப் பட்டியல் நீண்டதாக இருக்கலாம்... ஆனால் பல ஆதாரங்கள் தானாக உருவாக்கப்படுவது போல (அதாவது CloudFormation), அவற்றின் தணிக்கையை தானியக்கமாக்குவதும் சாத்தியமாகும். இது வீட்டில் தயாரிக்கப்பட்ட ஸ்கிரிப்ட், குறைபாடுகள் உள்ளதா என்று புதிய பொருட்களை ஸ்கேன் செய்யும், அல்லது CI/CD செயல்பாட்டில் பாதுகாப்பு தணிக்கை போன்றவை... இதைத் தவிர்க்க பல எளிய விருப்பங்கள் உள்ளன.
கேபிடல் ஒன் முதலில் ஓட்டை போட்டிருந்தால்... எதுவும் நடந்திருக்காது என்பதுதான் கதையின் "வேடிக்கையான" பகுதி. எனவே, வெளிப்படையாக, அது உண்மையில் எப்படி என்று பார்க்க எப்போதும் அதிர்ச்சியாக இருக்கிறது அழகான எளிய ஒரு நிறுவனம் ஹேக் செய்யப்படுவதற்கு ஒரே காரணமாகிறது. குறிப்பாக கேபிடல் ஒன்று போன்ற பெரிய ஒன்று.
எனவே, உள்ளே ஹேக்கர் - அடுத்து என்ன நடந்தது?
சரி, EC2 நிகழ்விற்குள் நுழைந்த பிறகு... நிறைய தவறுகள் நடக்கலாம். நீங்கள் யாரையாவது அவ்வளவு தூரம் செல்ல அனுமதித்தால் நீங்கள் நடைமுறையில் கத்தி முனையில் நடக்கிறீர்கள். ஆனால் அது எப்படி S3 வாளிகளுக்குள் வந்தது? இதைப் புரிந்துகொள்ள, IAM பாத்திரங்களைப் பற்றி விவாதிப்போம்.
எனவே, AWS சேவைகளை அணுகுவதற்கான ஒரு வழி ஒரு பயனராக இருக்க வேண்டும். சரி, இது மிகவும் வெளிப்படையானது. உங்கள் பயன்பாட்டு சேவையகங்கள் போன்ற பிற AWS சேவைகளை உங்கள் S3 பக்கெட்டுகளுக்கான அணுகலை வழங்க விரும்பினால் என்ன செய்வது? அதற்குத்தான் IAM பாத்திரங்கள். அவை இரண்டு கூறுகளைக் கொண்டிருக்கின்றன:
- நம்பிக்கைக் கொள்கை - என்ன சேவைகள் அல்லது மக்கள் இந்தப் பாத்திரத்தைப் பயன்படுத்தலாம்?
- அனுமதிக் கொள்கை - இந்தப் பாத்திரம் எதை அனுமதிக்கிறது?
எடுத்துக்காட்டாக, EC2 நிகழ்வுகள் S3 பக்கெட்டை அணுக அனுமதிக்கும் IAM பாத்திரத்தை உருவாக்க விரும்புகிறீர்கள்: முதலில், EC2 (முழு சேவையும்) அல்லது குறிப்பிட்ட நிகழ்வுகள் அந்த பாத்திரத்தை "பயனேற்றிக்கொள்ள" முடியும் என்று ஒரு நம்பிக்கைக் கொள்கையை இந்தப் பாத்திரம் அமைக்க வேண்டும். ஒரு பாத்திரத்தை ஏற்றுக்கொள்வது என்பது செயல்களைச் செய்ய அவர்கள் பாத்திரத்தின் அனுமதிகளைப் பயன்படுத்தலாம். இரண்டாவதாக, ஒரு குறிப்பிட்ட வாளியை அணுகினாலும்... அல்லது 3க்கு மேல், கேபிடல் ஒன்னில் இருப்பதைப் போல, S700 இல் “பங்கு வகிக்கும்” சேவை/நபர்/வளம் எதையும் செய்ய அனுமதிக் கொள்கை அனுமதிக்கிறது.
நீங்கள் IAM பங்குடன் EC2 நிகழ்வில் இருந்தால், நீங்கள் பல வழிகளில் நற்சான்றிதழ்களைப் பெறலாம்:
- நீங்கள் நிகழ்வு மெட்டாடேட்டாவைக் கோரலாம்
http://169.254.169.254/latest/meta-dataமற்றவற்றுடன், இந்த முகவரியில் உள்ள எந்த அணுகல் விசைகளிலும் IAM பங்கைக் கண்டறியலாம். நிச்சயமாக, நீங்கள் ஒரு நிகழ்வில் இருந்தால் மட்டுமே.
- AWS CLI ஐப் பயன்படுத்தவும்...
AWS CLI நிறுவப்பட்டிருந்தால், அது IAM பாத்திரங்களின் சான்றுகளுடன் ஏற்றப்படும். நிகழ்வின் மூலம் வேலை செய்வது மட்டுமே எஞ்சியுள்ளது. நிச்சயமாக, அவர்களின் நம்பிக்கைக் கொள்கை திறந்திருந்தால், பைஜ் நேரடியாக எல்லாவற்றையும் செய்ய முடியும்.
எனவே IAM பாத்திரங்களின் சாராம்சம் என்னவென்றால், அவை சில ஆதாரங்களை மற்ற வளங்களில் உங்கள் சார்பாக செயல்பட அனுமதிக்கின்றன.
இப்போது நீங்கள் IAM இன் பாத்திரங்களைப் புரிந்து கொண்டீர்கள், பைஜ் தாம்சன் என்ன செய்தார் என்பதைப் பற்றி பேசலாம்:
- ஃபயர்வாலில் உள்ள ஒரு துளை வழியாக அவர் சேவையகத்திற்கான அணுகலைப் பெற்றார் (EC2 நிகழ்வு).
அது பாதுகாப்பு குழுக்கள்/ACLகள் அல்லது அவற்றின் சொந்த வலை பயன்பாட்டு ஃபயர்வால்கள் என இருந்தாலும், அதிகாரப்பூர்வ பதிவுகளில் கூறப்பட்டுள்ளபடி, துளையை அடைப்பது மிகவும் எளிதாக இருக்கும்.
- சர்வரில் ஒருமுறை, அவளே சேவையாளராக இருப்பதைப் போல அவளால் செயல்பட முடிந்தது
- இந்த 3+ பக்கெட்டுகளுக்கு S700 அணுகலை IAM சர்வர் பங்கு அனுமதித்ததால், அதை அணுக முடிந்தது
அந்த நிமிடத்திலிருந்து, அவள் செய்ய வேண்டியதெல்லாம் கட்டளையை இயக்க வேண்டும் List Bucketsபின்னர் கட்டளை Sync AWS CLI இலிருந்து...
. கிளவுட் உள்கட்டமைப்பு பாதுகாப்பு, DevOps மற்றும் பாதுகாப்பு நிபுணர்கள் ஆகியவற்றில் நிறுவனங்கள் அதிக முதலீடு செய்வது ஏன் இத்தகைய சேதத்தைத் தடுக்கிறது. மற்றும் எவ்வளவு மதிப்புமிக்க மற்றும் செலவு குறைந்த மேகம் நகரும்? மேலும் மேலும் இணைய பாதுகாப்பு சவால்களை எதிர்கொண்டாலும் கூட !
கதையின் ஒழுக்கம்: உங்கள் பாதுகாப்பை சரிபார்க்கவும்; வழக்கமான தணிக்கைகளை நடத்துதல்; பாதுகாப்புக் கொள்கைகளுக்கான குறைந்தபட்ச சலுகை என்ற கொள்கையை மதிக்கவும்.
( நீங்கள் முழு சட்ட அறிக்கையையும் பார்க்கலாம்).
ஆதாரம்: www.habr.com