AWS Bedrock சாவிகள் (keys) இப்போது ஒரு உள்முறை LLM கேட்வேயால் (gateway) பாதுகாக்கப்படுகின்றன. இது ஒரு ஃபின்டெக் (fintech) நிறுவனத்தில் உள்ள ஒவ்வொரு குழுவிற்கும் மாடல்களை அழைக்க அனுமதிக்கிறது, அதே நேரத்தில் ஒவ்வொரு கோரிக்கையும் ஒரு குழுவிற்கான டோக்கன் வரம்புடன் (token budget) இணைக்கப்பட்டுள்ளது. இந்த மாற்றம், IAM சான்றுகளை (credentials) repos மற்றும் notebooks ஆகியவற்றில் சிதறடிக்கும் பழக்கத்தை நிறுத்துகிறது; இந்த பழக்கம் ஏற்கனவே ஒரு மதிய நேரத்திலேயே நிறுவனத்தின் AI செலவை முழுமையாகத் தீர்த்துவிடும் நிலைக்குத் தள்ளியிருந்தது.

AWS சாவிகளை வழங்குவது ஏன் விரைவாக ஒரு குழப்பமாக மாறுகிறது

நிறுவனத்தில் உள்ள தொழில்நுட்பம் சாராத குழுக்கள், நிறுவனத்தின் மொழி மாடல்களை (language models) நேரடியாக அணுகக் கேட்டனர். காகித அளவில் பார்த்தால், எளிமையான பதில் என்பது AWS-இல் மாடல்களைச் செயல்படுத்துவதும், ஒவ்வொரு குழுவிற்கும் ஒரு IAM அனுமதியை வழங்குவதும் ஆகும். பத்து நிமிட வேலை, சில policy edits, அவ்வளவுதான்—குறைந்தபட்சம் கோட்பாட்டளவில் (in theory) இது முடிந்துவிடும்.

நடைமுறையில், IAM சான்றுகளை வழங்குவது மூன்று மறைமுகச் செலவுகளை உருவாக்குகிறது:

  • Credential sprawl – சாவிகள் .env கோப்புகள், CI pipelines, Jupyter notebooks மற்றும் ad-hoc scripts ஆகியவற்றில் போய் சேருகின்றன. சாவிகளை மாற்ற வேண்டியிருக்கும் போது (rotation), ஒவ்வொரு நகலும் ஒரு தோல்விப் புள்ளியாக (point of failure) மாறுகிறது.
  • Zero visibility – ஒரு பொதுவான சாவி, எந்தக் குழு அல்லது எந்தக் குறியீடு (code) பயன்பாட்டை உருவாக்குகிறது என்பதைக் கண்டறிய உதவாது. ஒரு கட்டுப்பாடற்ற லூப் (runaway loop) தொடங்கினால், யாரும் கவனிப்பதற்கு முன்பே முழு பட்ஜெட்டும் தீர்ந்துவிடக்கூடும்.
  • Operational overhead – யாருக்கு என்ன அனுமதி உள்ளது என்பதைக் கண்காணிப்பது, அணுகலைத் திரும்பப் பெறுவது மற்றும் பயன்பாட்டைத் தணிக்கை (auditing) செய்வது ஆகியவை விரைவாக ஒரு கைமுறை மற்றும் பிழையளிக்கக்கூடிய செயல்முறையாக மாறிவிடுகிறது.

இந்த "விரைவான தீர்வு" விரைவில் ஒரு பாதுகாப்பு மற்றும் செலவுப் பேரழிவாக மாறிவிடும் என்பதை ஃபின்டெக் குழு உணர்ந்தது.

அதற்குப் பதிலாக ஒரு reverse-proxy கேட்வேயை உருவாக்குதல்

ஒவ்வொரு உள் பயன்பாட்டிற்கும் (internal application) மற்றும் AWS Bedrock-க்கும் இடையில் ஒரு மெல்லிய reverse proxy-யை நுழைப்பதே தீர்வாக இருந்தது. இந்த proxy உண்மையான AWS சான்றுகளை ஒரு பாதுகாப்பான இடத்தில் (vault-secured location) வைத்திருக்கும் மற்றும் அழைப்பவர்களுக்கு குறுகிய கால, மனிதர்கள் எளிதில் புரிந்துகொள்ளக்கூடிய டோக்கன்களை (உதாரணமாக, lllkey_9f3c) வழங்கும்.

முக்கிய வடிவமைப்பு அம்சங்கள்:

  • AWS சான்றுகள் கேட்வேயை விட்டு வெளியேறாது – டெவலப்பர்களும் சேவைகளும் உண்மையான IAM சாவிகளை ஒருபோதும் பார்க்க முடியாது.
  • Per-token policy enforcement – ஒவ்வொரு டோக்கனும் ஒரு குறிப்பிட்ட மாடல் குடும்பத்திற்கு அல்லது அதிகபட்ச டோக்கன் எண்ணிக்கைக்கு மட்டுப்படுத்தப்படலாம்.
  • Full audit trail – ஒவ்வொரு கோரிக்கையும் ஒரு பெயருடன் பதிவு செய்யப்படுகிறது.

கேட்வே ஒரு கோரிக்கையை எவ்வாறு செயலாக்குகிறது

  1. Receive token – கிளையண்ட் தனது llmkey_… டோக்கனை HTTP header-இல் சேர்க்கிறது.
  2. Validate token – கேட்வே டோக்கனின் நிலை (active, not expired) மற்றும் கோரிக்கை ஒதுக்கப்பட்ட பட்ஜெட்டுக்குள் இருக்கிறதா என்பதைச் சரிபார்க்கிறது.
  3. Model whitelist – கோரப்பட்ட மாடல் அந்த டோக்கனுக்கு அனுமதிக்கப்பட்டதா என்பதை உறுதி செய்கிறது.
  4. Forward to Bedrock – சேமிக்கப்பட்ட IAM சான்றுகளைப் பயன்படுத்தி கோரிக்கை AWS-க்கு அனுப்பப்படுகிறது.
  5. Log and bill – டோக்கன் பயன்பாடு, மாடல் பெயர் மற்றும் செலவு மதிப்பீடு ஆகியவை அறிக்கையிடலுக்காக ஒரு மையத் தரவுத்தளத்தில் (central database) எழுதப்படுகின்றன.

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

நிறுவனம் எதைப் பெற்றது

  • Model control – குறைந்த செலவுள்ள மாடல் தேவைப்படும் குழுக்களை அதற்கு மட்டுமே கட்டுப்படுத்த முடியும், இதன் மூலம் அதிக திறன் கொண்ட விலையுயர்ந்த மாடல்களைத் தவறுதலாகப் பயன்படுத்துவதைத் தவிர்க்கலாம்.
  • Budget protection – டோக்கன்களுக்கு ஒரு கடுமையான டோக்கன் வரம்பு உள்ளது. வரம்பு எட்டப்படும்போது, கேட்வே அமைதியாகக் கூடுதல் கிரெடிட்களைப் பயன்படுத்துவதற்குப் பதிலாக ஒரு பிழையைத் (error) திருப்பி அனுப்புகிறது.
  • Attribution for finance – பயன்பாட்டுப் பதிவுகளின் அடிப்படையில் உருவாக்கப்பட்ட ஒரு டேஷ்போர்டு, எந்தக் குழு அல்லது சேவை AI-க்காக எவ்வளவு செலவிட்டது என்பதைத் துல்லியமாகக் காட்டுகிறது, இது ஒரு தெளிவற்ற spreadsheet-ஐ வெளிப்படையான அறிக்கையாக மாற்றுகிறது.

செயல்பாட்டு முறைம also (workflow) மாறியது. புதிய IAM policies இல்லை, secret rotation இல்லை மற்றும் சாவிகள் version control-இல் கசிவதற்கான அபாயமும் இல்லை.

எதிர் வாதம்: ஏன் ஒரு managed service-ஐப் பயன்படுத்தக்கூடாது?

ஒரு பொதுவான ஆட்சேபனை என்னவென்றால், ஒரு தனிப்பயன் கேட்வேயை (custom gateway) உருவாக்குவது பொறியியல் முயற்சி மற்றும் பராமரிப்பைச் சேர்க்கும் என்பதாகும். இந்த ஃபின்டெக் நிறுவனத்தின் விஷயத்தில், அனைத்து AI போக்குவரத்து மற்றும் பயன்பாட்டுத் தரவுகளையும் நிறுவனத்தின் firewall பின்னால் வைத்திருக்க வேண்டிய தேவை, மூன்றாம் தரப்பு தீர்வின் வசதியை விட முக்கியமானது. இந்த உள்முறை proxy-க்கு ஒரு வார இறுதி நேர மேம்பாடு தேவைப்பட்டது, ஆனால் இது முறையற்ற சாவி விநியோக அணுகுமுறையினால் ஏற்பட்ட மாதக்கணக்கிலான சாவி சுத்திகரிப்பு மற்றும் பட்ஜெட் மீறல்களைத் தவிர்த்தது.

முக்கியக் கருத்து (Takeaway)

AWS Bedrock சாவிகளை வழங்குவது என்பது விரைவாக ஒரு பாதுகாப்பு மற்றும் பட்ஜெட் சிக்கலாக மாறும் ஒரு குறுக்குவழியாகும். ஒரு வார இறுதியில் உருவாக்கப்பட்ட ஒரு சிறிய reverse-proxy கேட்வே, சான்றுகளை மையப்படுத்துகிறது, குழு வாரியான வரம்புகளை அமலாக்குகிறது மற்றும் நிதித் துறைக்குத் தேவையான தணிக்கைப் பதிவை வழங்குகிறது. கட்டுப்பாட்டை விட்டுக்கொடுக்காமல் பல குழுக்கள் LLM-களைப் பரிசோதிக்க விரும்பும் எந்தவொரு நிறுவனத்திற்கும், இந்த கேட்வே அணுகுமுறை தவிர்க்கப்பட்ட விபத்துகள் மற்றும் தெளிவான செலவுத் தெரிவு மூலம் தன்னையே ஈடுகட்டிக் கொள்ளும்.