கடவுச்சொல்லைத் தவிர்க்க முடிந்தால், அதைப் பாதுகாக்க வேண்டிய அவசியம் என்ன?

வழக்கமானது என்று நாம் கருதிப் பழகிய பிரச்சினை

கிட்டத்தட்ட ஒவ்வொரு இணையப் பயன்பாட்டிலும் நிர்வாகக் கட்டுப்பாட்டுப் பலகம் உள்ளது. பொதுவாக, அந்தப் பலகைக்கு உள்நுழைவு முகவரி, அங்கீகாரப் படிவம், பயனர்பெயர், கடவுச்சொல் ஆகியவை இருக்கும்.

இந்த அமைப்புக்கு நாம் மிகவும் பழகிவிட்டோம்; எல்லாமே இப்படித்தான் செயல்பட வேண்டுமா என்ற கேள்வியைக் கேட்பதையே கிட்டத்தட்ட நிறுத்திவிட்டோம்.

உங்களிடம் ஒரே ஒரு தளம் இருக்கும்போது, இந்தப் பிரச்சினை பெரிதாகத் தெரியாது. வலுவான கடவுச்சொல்லை உருவாக்கி, இரு-காரணி அங்கீகாரத்தை இயக்கி, உள்நுழைவு முயற்சிகளுக்கு வரம்பு அமைத்துவிட்டு வேலையைத் தொடரலாம்.

ஆனால் திட்டங்கள் பத்து, இருபது அல்லது முப்பதாகும்போது என்ன நடக்கும்?

என்னைப் பொறுத்தவரை, முப்பதுக்கும் மேற்பட்ட தனித்த மென்பொருள் திட்டங்களை ஒன்றிணைக்கும் DigiMeld சூழலமைப்பைப் பற்றிப் பேசுகிறேன். ஒவ்வொன்றுக்கும் தனித்த கட்டமைப்பு, சேவையகத் தர்க்கம், நிர்வாக இடைமுகம் உள்ளன.

எனவே, ஒவ்வொன்றுக்கும் நிர்வாக அணுகல் வழிமுறை தேவைப்படுகிறது.

நீண்ட காலமாக நான் வழக்கமான அணுகுமுறையையே பயன்படுத்தினேன்: தனித்தனி நிர்வாகக் கணக்குச் சான்றுகள், வலுவான கடவுச்சொற்கள், அவற்றை உலாவியில் சேமித்தல்.

அது செயல்பட்டது.

ஆனால் ஒரு கட்டத்தில் நான் யோசித்தேன்: இத்தனை நிர்வாகக் கடவுச்சொற்களை நான் ஏன் சேமித்து வைத்திருக்க வேண்டும்? சேவையகங்களை மட்டுமல்ல, அவற்றை அணுகுவதற்கான வழிகளையும் நான் ஏன் பாதுகாக்க வேண்டும்?

இந்தத் தேவையை முற்றிலுமாகத் தவிர்க்க முடியாதா?

பின்னர் என் தீர்வின் அடிப்படையாக அமைந்த ஒரு கருத்துக்கு வந்தேன்:

நிரந்தர நுழைவாயிலைப் பாதுகாப்பதற்குப் பதிலாக, தற்காலிகமாக அணுகலைப் பெறுவதற்கான உரிமையைப் பாதுகாப்பது நல்லதாக இருக்கலாம்.

வழக்கமான உள்நுழைவுப் பக்கமே இல்லாமல் இருந்தால் என்ன?

என் திட்டங்களில் பாரம்பரிய நிர்வாக அங்கீகார மாதிரியைத் தவிர்க்க முடிவு செய்தேன்.

உள்நுழைவுப் படிவத்தை மறைப்பது மட்டுமல்ல.

முகவரியை மாற்றுவதுமல்ல.

கடவுச்சொல்லைவிட இன்னும் சிக்கலான கடவுச்சொல்லால் அதை மாற்றுவதுமல்ல.

எப்போதும் இருக்கும் கடவுச்சொல் அடிப்படையிலான உள்நுழைவு தேவையையே நீக்குவது.

நிச்சயமாக, நிர்வாக இடைமுகங்கள் மறைந்துவிடவில்லை. பயன்பாடுகளை நிர்வகிக்க அவை இன்னமும் அவசியம்.

அவற்றுக்கான அணுகலைப் பெறும் முறைதான் மாறியது.

இப்போது, இணைக்கப்பட்ட திட்டங்களின் நிர்வாகக் கட்டுப்பாட்டுப் பலகைகளில் நுழையச் சேமித்த பயனர்பெயரையும் கடவுச்சொல்லையும் உள்ளிட வேண்டியதில்லை.

அதற்குப் பதிலாக, MeldID என்ற எனது சொந்த அடையாளம் காணல் மற்றும் அணுகல் மேலாண்மை அமைப்பைப் பயன்படுத்துகிறேன்.

இதன் கருத்து மிகவும் எளிமையானது: நிர்வாக அணுகல் உண்மையில் தேவைப்படும் நேரத்தில், குறிப்பிட்ட பயனருக்கு, குறிப்பிட்ட திட்டத்திற்காக மட்டுமே வழங்கப்படுகிறது.

மேலும், ஒரு கணக்கு இருப்பது மட்டுமே நிர்வாகக் கட்டுப்பாட்டுப் பலகையைத் திறக்கும் உரிமையை அளிப்பதில்லை.

அந்த உரிமை தனியாக வழங்கப்பட வேண்டும்.

ஒரு நிமிடத்திற்கு முன்பு இல்லாத அணுகல்

முழுக் கருத்தாக்கத்திலும் இதுவே மிகவும் சுவாரசியமான பகுதி என்று சொல்லலாம்.

பாரம்பரிய மாதிரியில், நிர்வாகியிடம் எப்போதும் உள்நுழைவதற்கான வழிகள் இருக்கும். அவை செல்லுபடியாக இருக்கும் வரை, இன்று, நாளை அல்லது ஒரு மாதம் கழித்து அவர் அவற்றைப் பயன்படுத்தலாம்.

இந்தக் கொள்கையை மாற்ற முடிவு செய்தேன்.

நிரந்தர நிர்வாகக் கணக்குச் சான்றுகளுக்குப் பதிலாக, தற்காலிகமாக உள்நுழைவைத் தொடங்கும் வாய்ப்பு பயன்படுத்தப்படுகிறது.

நம்பகமான மொபைல் சாதனத்தின் மூலம் கோரிக்கையின் பேரில் அது உருவாக்கப்படுகிறது; அதில் குறியாக்கவியல் ரீதியாக வலுவான சீரற்ற கூறு இடம்பெறும், மேலும் அதற்கு வரையறுக்கப்பட்ட செல்லுபடிக் காலமும் உண்டு.

ஆனால் அத்தகைய தற்காலிக இணைப்பை வைத்திருப்பது மட்டுமே அணுகலைப் பெறுவதைக் குறிக்காது.

இது அடிப்படையான விஷயம்.

யாரோ ஒருவர் எப்படியோ அந்த இணைப்பைப் பெற்றுவிட்டதாக வைத்துக்கொள்வோம். முகவரியின் ரகசியத்தன்மையை மட்டுமே நம்பி அமைக்கப்பட்ட வழக்கமான அமைப்பில், அத்தகைய கசிவு கடுமையான பிரச்சினையாகலாம்.

என் மாதிரியில், அந்த இணைப்பு உறுதிப்படுத்தல் செயல்முறையைத் தொடங்க மட்டுமே உதவுகிறது.

தொடர, நம்பகமான MeldID மொபைல் சாதனத்தின் மூலம் தனியான அனுமதி தேவை.

அதற்கான உறுதிப்படுத்தல் இல்லாமல் நிர்வாக அமர்வு உருவாக்கப்படாது.

அதனால்தான் தற்காலிக இணைப்பை கடவுச்சொல்லுக்கு மாற்றாக அல்ல, அணுகல் வழங்கும் செயல்முறையின் ஒரு கூறாகக் கருதுகிறேன்.

எங்கு செல்ல வேண்டும் என்பதை அறிவதும், நுழைய உரிமை பெற்றிருப்பதும் முற்றிலும் வேறுபட்டவை.

தொலைபேசி அணுகலை நிர்வகிக்கும் கருவியாகிறது

இந்த மாதிரியில், வழக்கமான ஒருமுறைப் பயன்பாட்டுக் குறியீடு உருவாக்கியை விட மொபைல் சாதனம் மிக முக்கியமான பங்கு வகிக்கிறது.

நிர்வாக அணுகல் தொடர்பான செயல்களை உறுதிப்படுத்த அது பயன்படுகிறது.

நான் நிர்வாகக் கட்டுப்பாட்டுப் பலகையைத் திறக்க விரும்பும்போது, MeldID வழியாக உறுதிப்படுத்துமாறு அமைப்பு கோருகிறது.

நம்பகமான சாதனத்தில் அந்தக் கோரிக்கையைப் பார்த்து, செயலை உறுதிப்படுத்துகிறேன்.

சரிபார்ப்பு வெற்றியடைந்த பிறகே, உள்நுழைவு செயல்முறையைத் தொடர அமைப்பு அனுமதிக்கிறது.

மேலும், இந்த உறுதிப்படுத்தல் தொலைபேசி திறக்கப்பட்டிருப்பதுடன் மட்டும் தொடர்புடையதல்ல; அது குறிப்பிட்ட செயலுடன் இணைக்கப்பட்டுள்ளது.

மொபைல் பயோமெட்ரிக்ஸ் பயனரைச் சாதனத்திலேயே சரிபார்க்கிறது; சேவையகப் பக்கம் பதிவு செய்யப்பட்ட சாதனத்திலிருந்து வரும் குறியாக்கவியல் உறுதிப்படுத்தலைச் சரிபார்க்கிறது.

இந்த அணுகுமுறை, கடவுச்சொல்லை மட்டுமே அல்லது பயனர் உள்நுழைவை உறுதிப்படுத்தியதாகக் கூறும் செய்தியை மட்டுமே நம்பியிருக்க வேண்டிய தேவையைத் தவிர்க்கிறது.

இதில் இன்னொரு நன்மையும் உள்ளது: நம்பகமான சாதனங்களை நிர்வகிக்க முடியும்.

ஒரு சாதனத்தை அணுகலை உறுதிப்படுத்த இனி பயன்படுத்தக் கூடாது என்றால், அதன் நம்பகமான நிலையைத் திரும்பப் பெறலாம்.

அதன் பிறகு, தொடர்புடைய செயல்பாடுகளை அங்கீகரிக்கும் செல்லுபடியான கருவியாக அந்தச் சாதனம் இருக்காது.

ஒரே அமைப்பு — பல சுயாதீனத் திட்டங்கள்

இந்த வழிமுறையை உருவாக்கத் தொடங்கியபோது, ஒவ்வொரு திட்டத்தின் சுயாதீனத்தையும் தக்கவைத்துக்கொள்வது முக்கிய சவால்களில் ஒன்றாக இருந்தது.

எல்லா நிர்வாகக் கட்டுப்பாட்டுப் பலகைகளையும் ஒரு பெரிய பயன்பாட்டில் ஒன்றிணைக்க நான் விரும்பவில்லை.

ஒவ்வொரு DigiMeld சேவையும் அதன் சொந்த தர்க்கம், அமைப்புகள், பயனர்கள், தரவு ஆகியவற்றைத் தொடர்ந்து நிர்வகிக்க வேண்டும்.

எனவே, இந்த இரண்டு பணிகளையும் பிரித்தேன்.

அடையாளம் காணலுக்கும் நிர்வாக அணுகல் அனுமதி வழங்குவதற்கும் MeldID பொறுப்பேற்கிறது.

அந்தத் திட்டத்தின் சொந்த நிர்வாகச் செயல்பாடுகளுக்கும், தற்போதைய உரிமைகளைச் சரிபார்ப்பதற்கும் அந்தத் திட்டமே பொறுப்பேற்கிறது.

இவ்வாறு, பயன்பாடுகளையே மையப்படுத்த வேண்டிய அவசியமின்றி, அணுகல் மேலாண்மைக்கான மையப்படுத்தப்பட்ட மாதிரி உருவானது.

மேலும், உரிமைகள் தனித்தனியாக வழங்கப்படுகின்றன.

MeldID கணக்கு இருப்பதற்காக மட்டும், ஒரு திட்டத்தின் நிர்வாகி மற்ற திட்டங்களையும் தானாக அணுக முடியாது.

ஒவ்வொரு நிர்வாகப் பகுதிக்கும் அனுமதிக்கப்பட்ட பயனர்களின் தனித்த வட்டத்தை வரையறுக்கலாம்.

அதே நேரத்தில், சாதாரண பயனர்களுக்கான உரிமைகளும் நிர்வாக அதிகாரங்களும் தனித்தனியாக உள்ளன.

டஜன் கணக்கான சேவைகளைக் கொண்ட சூழலமைப்புக்கு இது குறிப்பாக வசதியாக இருந்தது.

நிரந்தர அணுகலைவிட தற்காலிக அணுகல் எனக்கு ஏன் பிடித்திருக்கிறது

இந்த அமைப்பில் நான் திட்டமிட்டு சேர்த்துள்ள மற்றொரு கொள்கை உள்ளது.

நிர்வாக அணுகல் காலவரையின்றித் தொடரக் கூடாது.

அனுமதி குறிப்பிட்ட காலத்துக்கு மட்டுமே செல்லுபடியாகும்; பயனர் உலாவியில் தொடர்ந்து வேலை செய்தாலும் அது காலாவதியாகும்.

அந்தக் காலம் முடிந்த பிறகும் வேலையைத் தொடர, மீண்டும் உறுதிப்படுத்தும் செயல்முறை தேவை.

இதனால், ஒருமுறை செய்யப்பட்ட அங்கீகாரம் நிரந்தரமாகச் செயல்படும் உரிமையாக மாறுவது தடுக்கப்படுகிறது.

ஆனால் காலவரம்பு மட்டும் போதாது.

ஏற்கெனவே வழங்கப்பட்ட அணுகலை முன்கூட்டியே நிறுத்தும் திறனும் முக்கியம்.

அதற்காக, நிர்வாக அனுமதிகளை மையமாகத் திரும்பப் பெறும் வசதி MeldID-இல் உள்ளது.

அனுமதி திரும்பப் பெறப்படும்போது, இணைக்கப்பட்ட திட்டங்கள் அதற்கான நிகழ்வைப் பெற்று, தொடர்புடைய நிர்வாக அமர்வுகளை ரத்து செய்கின்றன.

இவ்வாறு, பயனர் வெற்றிகரமாக உள்நுழைந்தவுடன் அணுகல் மேலாண்மை முடிந்துவிடுவதில்லை.

அதிகாரங்களை வழங்கும் திறனுக்கு இணையாக, அவற்றைத் திரும்பப் பெறும் திறனையும் முக்கியமானதாகக் கருதுகிறேன்.

அதேவேளை, பகிர்ந்தளிக்கப்பட்ட அமைப்பு நிகழ்வுகள் அனுப்பப்படுவதில் ஏற்படும் தாமதங்கள், சில கூறுகள் தற்காலிகமாகக் கிடைக்காமை மற்றும் பிற செயல்பாட்டு நிலைமைகளையும் கணக்கில் எடுத்துக்கொள்ள வேண்டும். அமர்வுகளின் செல்லுபடிக் கால வரம்பு கூடுதல் பாதுகாப்பு எல்லையாகச் செயல்படுகிறது.

அன்றாட வேலையில் என்ன மாறியது?

முதலில், சேமித்திருந்த நிர்வாகக் கடவுச்சொற்களைத் தொடர்ந்து பயன்படுத்த வேண்டிய அவசியம் நீங்கியது.

இணைக்கப்பட்ட ஒவ்வொரு நிர்வாகக் கட்டுப்பாட்டுப் பலகையிலும் நுழையத் தேவையான கணக்குச் சான்றுகளின் தொகுப்பை உலாவியில் வைத்திருக்க வேண்டியதில்லை.

அதற்குப் பதிலாக, ஒரே வழிமுறையின் மூலம் அனுமதிகளை நிர்வகிக்கிறேன்.

தேவையான திட்டத்தைத் தேர்ந்தெடுத்து, அணுகலை உறுதிப்படுத்தி, வேலையைத் தொடர்கிறேன்.

நிர்வாக அணுகல் இனி தேவையில்லாதபோது, அதைத் திரும்பப் பெறலாம்.

புதிய திட்டம் சேரும்போது, நிர்வாக அங்கீகார அமைப்பை முழுவதுமாக மீண்டும் வடிவமைக்கத் தேவையில்லை என்பது குறிப்பாக வசதியானது.

ஏற்கெனவே உள்ள மாதிரியுடன் அதை இணைத்து, தேவையான அனுமதிகளை வரையறுத்தால் போதும்.

நிச்சயமாக, இதனால் எல்லாப் பாதுகாப்பு அபாயங்களும் மறைந்துவிட்டன என்று அர்த்தமல்ல.

தற்காலிக அனுமதிகள், நம்பகமான சாதனங்கள், சேவையக அமர்வுகள், மையக் கட்டமைப்பு ஆகியவற்றுக்கும் பாதுகாப்பு தேவை.

ஆனால் ஒவ்வொரு பயன்பாட்டுக்கும் நிர்வாகக் கடவுச்சொற்களை நிர்வகிக்கும் ஒரே பிரச்சினையைத் தனித்தனியாகத் தீர்க்க வேண்டியதில்லை.

இதுவே எனது ஆரம்ப இலக்குகளில் ஒன்று.

இத்தகைய தொழில்நுட்பங்கள் ஏற்கெனவே இல்லையா?

நிச்சயமாக இருக்கின்றன.

கடவுச்சொல்லற்ற அங்கீகாரம், சிறப்புரிமை அணுகல் மேலாண்மை, தற்காலிக அனுமதிகள், நம்பகமான சாதனங்கள் மூலம் உறுதிப்படுத்தல் ஆகியவை தகவல் பாதுகாப்புத் துறையில் நீண்ட காலமாக அறியப்பட்டவை.

Identity and Access Management, Privileged Access Management அமைப்புகளிலும், Zero Trust கருத்தாக்கங்களிலும் இத்தகைய அணுகுமுறைகளைக் காணலாம்.

இந்தக் கொள்கைகளை நான் கண்டுபிடித்ததாகக் கூறவில்லை.

எனது பணி வேறானது.

DigiMeld கட்டமைப்பின் குறிப்பிட்ட சிக்கல்களைத் தீர்த்து, பல சுயாதீனத் திட்டங்களுக்கான நிர்வாக அணுகலை நிர்வகிக்க உதவும் சொந்த ஒருங்கிணைந்த அமைப்பை உருவாக்க வேண்டியிருந்தது.

இதன் விளைவாக, எனது தேவைகளுக்கு ஏற்ற ஒரே கட்டமைப்பில் பல அறியப்பட்ட அணுகுமுறைகளை ஒன்றிணைத்தேன்.

மேலும், பொறியியல் பணியின் மதிப்பு முற்றிலும் புதிய தொழில்நுட்பத்தைக் கண்டுபிடிப்பதில் மட்டுமே இல்லை என்று கருதுகிறேன்.

சில நேரங்களில், பிரச்சினையைச் சரியாக வரையறுத்து, அதற்குப் பொருத்தமான தீர்வைக் கண்டறிவதில்தான் அதன் மதிப்பு இருக்கிறது.

MeldID நிர்வாகக் கட்டுப்பாட்டுப் பலகைகளுக்கு மட்டுமல்ல

இங்கே ஒரு விஷயத்தைத் தனியாகத் தெளிவுபடுத்த வேண்டும்.

எனது சொந்த நிர்வாக அணுகலுக்கான கருவியாக மட்டுமே MeldID உருவாக்கப்படவில்லை.

டெவலப்பர்கள் தங்கள் சொந்தப் பயன்பாடுகளில் அடையாளம் காணல் மற்றும் உள்நுழைவு உறுதிப்படுத்தல் வழிமுறைகளை ஒருங்கிணைக்க SDK-ஐயும் இது வழங்குகிறது.

இந்த SDK இலவசமாகவும் கிடைக்கிறது.

எடுத்துக்காட்டாக, மூன்றாம் தரப்பு டெவலப்பர், பயனர் அங்கீகாரத்தை உறுதிப்படுத்தும் கூடுதல் அடுக்காக MeldID-ஐப் பயன்படுத்தலாம்.

ஒரு பயன்பாட்டில் பயனர்பெயர் மற்றும் கடவுச்சொல் வழியிலான பாரம்பரிய உள்நுழைவு தொடர்ந்தாலும், அந்த விவரங்களைச் சரியாக உள்ளிடுவது மட்டும் அங்கீகாரத்தை முடிக்கப் போதாமல் இருக்கலாம்.

நம்பகமான மொபைல் சாதனத்துக்கு ஒரு கோரிக்கை அனுப்பப்படும்; அங்கே பயனர் உள்நுழைவு முயற்சியை உறுதிப்படுத்தலாம் அல்லது நிராகரிக்கலாம்.

கணக்குச் சான்றுகள் கசிந்தால், அனுமதியற்ற அணுகல் ஏற்படும் அபாயத்தைக் குறைக்க இது உதவுகிறது.

MeldID-இன் பொதுப் பயன்பாட்டுக்குக் கிடைக்கும் இந்த வசதியையும், DigiMeld திட்டங்களுக்காக நான் உருவாக்கிய நிர்வாக அணுகல் மாதிரியையும் வேறுபடுத்திப் பார்ப்பது முக்கியம்.

இவை நம்பிக்கை மற்றும் செயல்களை உறுதிப்படுத்துதல் என்ற பொதுவான கொள்கைகளைப் பயன்படுத்தினாலும், வெவ்வேறு சிக்கல்களைத் தீர்க்கின்றன.

பாதுகாப்பு என்பது ஏற்கெனவே இருப்பதைப் பாதுகாப்பது மட்டுமல்ல

இந்த அமைப்பை உருவாக்கும் பணி, வழக்கமான அங்கீகார வழிமுறைகளை வேறொரு கோணத்தில் பார்க்கச் செய்தது.

வரலாற்றுக் காரணங்களால் தொடர்ந்து இருக்கும் விஷயங்களைப் பாதுகாக்கவே நாம் அடிக்கடி முயல்கிறோம்.

புதிய சரிபார்ப்புகள், கட்டுப்பாடுகள், கூடுதல் கடவுச்சொற்கள், பாதுகாப்பு அடுக்குகள் ஆகியவற்றைச் சேர்க்கிறோம்.

சில நேரங்களில் இது உண்மையிலேயே அவசியம்.

ஆனால் சில சமயங்களில் வேறொரு கேள்வியைக் கேட்பது பயனுள்ளதாக இருக்கும்:

நாம் பாதுகாக்கும் அந்த வழிமுறை, முன்பு இருந்த அதே வடிவில் கட்டாயம் இருக்க வேண்டுமா?

என் விஷயத்தில், பதில் இல்லை என்பதாக இருந்தது.

எனக்கு எப்போதும் கிடைக்கக்கூடிய நிர்வாக உள்நுழைவுப் படிவம் தேவையில்லை.

தேவைப்படும் நேரத்தில் பாதுகாப்பாக நிர்வாக அதிகாரங்களைப் பெறும் வழியே எனக்குத் தேவைப்பட்டது.

இவை இரண்டு வெவ்வேறு பணிகள்.

முதலாவதிலிருந்து இரண்டாவதற்கு மாறியது தொழில்நுட்பக் கட்டமைப்பை மட்டுமல்ல, திட்டங்களுடன் அன்றாடம் பணிபுரியும் முறையையும் மாற்றியது.

இறுதிப் புள்ளி அல்ல; தேர்ந்தெடுத்த திசை

இன்று இந்தக் கட்டமைப்பு DigiMeld சூழலமைப்பின் பெரும்பகுதியில் செயல்படுகிறது.

மீதமுள்ள திட்டங்கள் படிப்படியாகப் புதிய நிர்வாக அணுகல் மாதிரிக்கு மாற்றப்படுகின்றன.

ஒவ்வொரு பயன்பாடும் சரியாகச் செயல்படுகிறதா என்பதைச் சரிபார்த்தபடி, இந்த மாற்றத்தைப் படிப்படியாகச் செய்கிறேன். மாற்றம் முடிந்ததும், முழு அமைப்பையும் கூடுதலாகத் தணிக்கை செய்யத் திட்டமிட்டுள்ளேன்.

இடைமுகத்தின் சில பகுதிகளும் அமர்வு மேலாண்மை விதிகளும் இன்னும் மாறக்கூடும்.

ஆனால் அடிப்படைக் கருத்து ஏற்கெனவே முடிவாகிவிட்டது.

எனது டஜன் கணக்கான திட்டங்களை நிர்வகிக்க, டஜன் கணக்கான நிர்வாகக் கடவுச்சொற்களைத் தொடர்ந்து சேமித்து பயன்படுத்த வேண்டிய மாதிரிக்குத் திரும்ப நான் விரும்பவில்லை.

அதே நேரத்தில், எனது செயலாக்கம் அனைவருக்கும் பொருந்தும் தீர்வு என்று நான் கருதவில்லை.

வெவ்வேறு நிறுவனங்களுக்கு வெவ்வேறு தேவைகள், கட்டமைப்புகள், அச்சுறுத்தல் மாதிரிகள், நிர்வாக முறைகள் உள்ளன.

DigiMeld சூழலமைப்புக்கு வசதியாகவும் பொருத்தமாகவும் இருப்பது, மற்றொரு டெவலப்பருக்கு உகந்ததாக இருக்க வேண்டிய அவசியமில்லை.

ஆனால் அதிகாரங்களைத் தற்காலிகமாக வழங்கும் கொள்கை கவனத்திற்குரியது.

முடிவாக

புதிய அங்கீகார முறையைக் கண்டுபிடித்தவன் என்று என்னைக் கருதுவதால் இந்த அனுபவத்தைப் பகிர்ந்துகொள்ள நான் முடிவு செய்யவில்லை.

அல்லது, மற்றொரு அமைப்பை முற்றிலும் பாதுகாப்பானது என்று முன்வைக்க விரும்புவதாலும் அல்ல.

முழுமையான பாதுகாப்பு என்று ஒன்று இல்லை.

இந்தக் கேள்வியை அணுகும் விதமே சுவாரசியமாக இருக்கிறது என்று எனக்குத் தோன்றுகிறது.

நிரந்தர நிர்வாக உள்நுழைவாயிலை முடிவில்லாமல் பாதுகாப்பதற்குப் பதிலாக, அது இருக்க வேண்டிய அவசியத்தை மறுபரிசீலனை செய்யலாம்.

பல கடவுச்சொற்களைச் சேமிப்பதற்குப் பதிலாக, தற்காலிக அனுமதிகளைப் பயன்படுத்தலாம்.

முதல் அங்கீகாரத்திற்குப் பிறகு தானாகவே நம்புவதற்குப் பதிலாக, குறிப்பிட்ட அதிகாரங்களை வழங்குவதை உறுதிப்படுத்தலாம்.

அமர்வு முடியும் வரை காத்திருப்பதற்குப் பதிலாக, அணுகலை மையமாகத் திரும்பப் பெறும் வசதியை ஏற்படுத்தலாம்.

இறுதியாக, ஒவ்வொரு திட்டத்துக்கும் தனித்தனி உள்நுழைவு வழிமுறையை வைத்திருப்பதற்குப் பதிலாக, பயன்பாடுகளின் சுயாதீனத்தைத் தக்கவைத்தபடி நிர்வாக அணுகல் அனுமதியை நிர்வகிக்கும் ஒருங்கிணைந்த அமைப்பை உருவாக்கலாம்.

இத்தகைய அணுகுமுறை, பாதுகாப்பு மீறல் ஏற்படுவதற்கான சாத்தியத்தை முற்றிலுமாக நீக்குகிறது என்று நான் கூறவில்லை.

நிரந்தரமாக இருக்கும் கணக்குச் சான்றுகளைப் பாதுகாப்பதிலிருந்து, அதிகாரங்களை கட்டுப்பாட்டுடன் வழங்குவதிலும் திரும்பப் பெறுவதிலும் கவனத்தை மட்டும் மாற்றுகிறது.

சில நேரங்களில் தாக்குதலுக்குள்ளாகக்கூடிய பரப்பைக் குறைப்பதற்கான மிகச் சிறந்த வழி, இன்னொரு பாதுகாப்பு வழிமுறையைச் சேர்ப்பதல்ல; அமைப்பு செயல்படுவதற்கு அவசியமில்லாத ஒன்றைத் தவிர்ப்பதாக இருக்கலாம்.

இந்த எண்ணத்திலிருந்துதான் எனக்கு MeldID Admin Gateway-இன் கதை தொடங்கியது.