ഡെലിഗേറ്റ് ചെയ്ത ആക്സസ്

ആളുകൾക്ക് ആവശ്യമുള്ള ആക്‌സസ് മാത്രം കൃത്യമായി നൽകുക — മറ്റൊന്നും നൽകരുത്

ഒരു ഡെവലപ്പറെ കൊണ്ടുവരിക, ബില്ലിംഗ് നിങ്ങളുടെ അക്കൗണ്ടന്റിന് കൈമാറുക, ഒരു ക്ലയന്റിന് അവരുടെ സ്വന്തം സൈറ്റുകളിലേക്ക് റീഡ്-ഒൺലി ആക്സസ് നൽകുക, അല്ലെങ്കിൽ ഞങ്ങളുടെ സപ്പോർട്ട് ടീമിനെ ഒരു പ്രശ്നം പരിശോധിക്കാൻ അനുവദിക്കുക. ഓരോ അനുമതിയും നിർവചിക്കപ്പെട്ട പ്രത്യേക അനുമതികളുള്ള ഒരു പങ്കാണ്, ഇത് ഒരു സ്ഥാപനത്തിലേക്ക് പരിമിതപ്പെടുത്തിയതും, ഡാറ്റാബേസിൽ നടപ്പിലാക്കിയതും, മാറ്റങ്ങൾ വരുത്താനാകാത്ത ഒരു ഓഡിറ്റ് ലോഗിലേക്ക് രേഖപ്പെടുത്തിയതുമാണ്.

ഒരു അക്കൗണ്ടുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന നിരവധി ആളുകൾ, ഓരോരുത്തർക്കും അവരുടേതായ നിർദ്ദിഷ്ട അനുമതികൾ ഉണ്ട്.
  • 94വിശദമായ അനുമതികൾ
  • 12അന്തർനിർമ്മിത റോളുകൾ
  • 8സ്റ്റാഫ് വിഭാഗങ്ങൾ
  • 7,00,000+ലോകമെമ്പാടും ഹോസ്റ്റ് ചെയ്‌ത സൈറ്റുകൾ

ആക്സസ് എന്നത് ഒരു അംഗത്വമാണ്, പങ്കിട്ട പാസ്‌വേഡല്ല

ഒറ്റ ലോഗിൻ പങ്കിടുന്നത് അക്കൗണ്ട് ആക്സസ്സിൽ പ്രശ്നങ്ങൾ ഉണ്ടാക്കാൻ കാരണമാകുന്നു. Zinn Digital®-ൽ ഓരോ വ്യക്തിക്കും അവരുടേതായ വ്യക്തിത്വമുണ്ട്, ആക്സസ് എന്നത് ഒരു അംഗത്വമാണ് — ഒരു ഉപയോക്താവ്, ഒരു സ്ഥാപനം, ഒരു പങ്ക് — അത് നിങ്ങൾക്ക് സ്വതന്ത്രമായി നൽകാനോ മാറ്റാനോ റദ്ദാക്കാനോ കഴിയും.

നിങ്ങളുടെ സ്വന്തം വ്യക്തിത്വം, എപ്പോഴും

ഓരോ പങ്കാളിയും ഞങ്ങളുടെ ഐഡന്റിറ്റി ലെയറായ Keycloak വഴി അവരവരായിത്തന്നെ സൈൻ ഇൻ ചെയ്യുന്നു. ആരും നിങ്ങളുടെ പാസ്‌വേഡ് ടൈപ്പ് ചെയ്യുന്നില്ല, ആരും ബ്രൗസർ സെഷൻ പങ്കിടുന്നില്ല, കൂടാതെ ഒരാളെ നീക്കം ചെയ്യുന്നത് പാസ്‌വേഡ് മാറ്റുന്നതിനും മറ്റാർക്കൊക്കെ അതറിയാമായിരുന്നു എന്ന് കണ്ടെത്തുന്നതിനും പകരം ഒരൊറ്റ നടപടിയാണ്.

ഓർഗനൈസേഷനുകൾ ഒരു ട്രീ ഘടന രൂപീകരിക്കുന്നു

അക്കൗണ്ടുകൾ ശ്രേണീബദ്ധമാണ് — ഒരു റീസെല്ലർ ഓർഗനൈസേഷൻ ക്ലയന്റ് ഓർഗനൈസേഷനുകളെ ഉൾക്കൊള്ളുന്നു, ക്ലയന്റ് ഓർഗനൈസേഷനുകൾ സൈറ്റുകളെ ഉൾക്കൊള്ളുന്നു. ഒരു അംഗത്വം ഒരു ഓർഗനൈസേഷനും അതിന് കീഴിലുള്ള എല്ലാത്തിനും ബാധകമാണ്, അതിനാൽ നിങ്ങളുടെ മറ്റ് ക്ലയന്റുകളെ വെളിപ്പെടുത്താതെ തന്നെ ഒരു ഏജൻസി ക്ലയന്റിന് അവരുടെ സ്വന്തം ഓർഗനൈസേഷന്റെ നിയന്ത്രണം കൈമാറാൻ നിങ്ങൾക്ക് കഴിയും.

ഡാറ്റാബേസിൽ ഐസൊലേഷൻ നടപ്പിലാക്കി

ടെനന്റ് വേർതിരിക്കൽ എന്നത് ഒരു തകരാറുമൂലം ഒഴിവാക്കപ്പെടാൻ സാധ്യതയുള്ള ആപ്ലിക്കേഷൻ കോഡിലെ ഒരു ഫിൽട്ടറല്ല. Postgres റോ-ലെവൽ സെക്യൂരിറ്റി ഓരോ അന്വേഷണത്തെയും കോളറുടെ ഓർഗനൈസേഷൻ സബ്‌ട്രീയിലേക്ക് പരിമിതപ്പെടുത്തുന്നു, അതിനാൽ നിങ്ങളുടെ പരിധിക്ക് പുറത്തുള്ള ഒരു അഭ്യർത്ഥനയ്ക്ക് തിരികെ നൽകാൻ ഒന്നുമുണ്ടാകില്ല.

അസാന്നിധ്യം അദൃശ്യമാണ്

നിങ്ങളുടെ പരിധിക്ക് പുറത്തുള്ള ഒരു സ്ഥാപനത്തെയോ സൈറ്റിനെയോ ആവശ്യപ്പെട്ടാൽ, അനുമതി സംബന്ധിച്ച പിശകിന് പകരം API ലളിതമായ 'കണ്ടെത്താനായില്ല' എന്ന മറുപടി നൽകുന്നു. അനുമതി സംബന്ധിച്ച പിശക് അത്തരം ഒരു റെക്കോർഡ് നിലവിലുണ്ടെന്ന് സ്ഥിരീകരിക്കും; എന്നാൽ 'കണ്ടെത്താനായില്ല' എന്നത് പുറത്തുനിന്നുള്ള ഒരാൾക്ക് യാതൊരു വിവരവും നൽകുന്നില്ല.

നാല് ഉപഭോക്തൃ റോളുകൾ, മുപ്പത്തിയഞ്ച് അനുമതികൾ

അനുമതികൾ വിശദമായ കീകൾ ആണ് — sites.restart അല്ലെങ്കിൽ billing.refund പോലുള്ള മൊഡ്യൂളും പ്രവർത്തനവും ചേർന്നവ — കൂടാതെ റോളുകൾ അവയെ ഒന്നിച്ച് ചേർക്കുന്നു. യഥാർത്ഥ ടീമുകൾക്ക് ആവശ്യമായ ഘടനകളെ നാല് റോളുകൾ ഉൾക്കൊള്ളുന്നു, അവയിൽ ഓരോന്നും ഞങ്ങൾ നൽകുന്ന ഡാറ്റയാണ്, അല്ലാതെ കോഡിൽ മറഞ്ഞിരിക്കുന്ന ലോജിക്കല്ല.

ഉടമസ്ഥൻ

പൂർണ്ണ നിയന്ത്രണം: ഉപസ്ഥാപനങ്ങൾ സൃഷ്ടിക്കുക, അംഗങ്ങളെ ക്ഷണിക്കുകയും നീക്കം ചെയ്യുകയും ചെയ്യുക, റോളുകൾ മാറ്റുക, API കീകൾ നിയന്ത്രിക്കുക, സൈറ്റുകൾ സൃഷ്ടിക്കുക, പുനരാരംഭിക്കുക, ശുദ്ധീകരിക്കുക, സസ്പെൻഡ് ചെയ്യുക, ഇല്ലാതാക്കുക, ബില്ലിംഗും ഇൻവോയ്സുകളും കൈകാര്യം ചെയ്യുക, ടിക്കറ്റുകൾ ഉന്നയിക്കുക, ഓഡിറ്റ് ലോഗ് വായിക്കുക. നിങ്ങൾക്കായി മാറ്റിവെക്കുന്ന റോൾ.

ബില്ലിംഗ് മാനേജർ

സ്ഥാപനം, അതിലെ അംഗങ്ങൾ, പ്ലാൻ കാറ്റലോഗ് എന്നിവ കാണുകയും ഇൻവോയ്സുകൾ, പേയ്‌മെന്റ് രീതികൾ, ചാർജുകൾ എന്നിവ കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു. ഒരു സൈറ്റ് പോലും നിർമ്മിക്കാനോ മാറ്റം വരുത്താനോ ഇല്ലാതാക്കാനോ ഉള്ള ആക്‌സസ് ഇല്ല — ഒരു ബാഹ്യ ബുക്ക് കീപ്പർക്ക് ഉണ്ടായിരിക്കേണ്ട കൃത്യമായ ഘടന.

ഡെവലപ്പർ

സൈറ്റുകൾ കാണുകയും നിർമ്മിക്കുകയും ചെയ്യുന്നു, സേവനങ്ങൾ പുനരാരംഭിക്കുന്നു, കാഷെ ഒഴിവാക്കുന്നു, API കീകൾ കൈകാര്യം ചെയ്യുന്നു, ടിക്കറ്റുകളിൽ പ്രവർത്തിക്കുന്നു. മനഃപൂർവ്വം ഒഴിവാക്കിയവ: ബില്ലിംഗ്, ഇൻവോയ്സുകൾ, പേയ്‌മെന്റ് രീതികൾ, അംഗങ്ങളുടെ മാനേജ്‌മെന്റ്, സൈറ്റ് താൽക്കാലികമായി നിർത്തൽ, സൈറ്റ് ഇല്ലാതാക്കൽ. നിങ്ങൾക്ക് ബിൽ ചെയ്യാനോ ഒന്നും നശിപ്പിക്കാനോ സാധിക്കാത്ത വിധത്തിൽ ഒരു കരാറുകാരന് നിർമ്മാണം നടത്താൻ കഴിയും.

വായിക്കാൻ മാത്രം

സ്ഥാപനം, അതിലെ അംഗങ്ങൾ, സൈറ്റുകൾ, ബില്ലിംഗ്, പ്ലാൻ കാറ്റലോഗ്, ടിക്കറ്റുകൾ, വിവർത്തന നില, ഓഡിറ്റ് ലോഗ് എന്നിവ കാണാൻ കഴിയും — എന്നാൽ ഇതിലൊന്നും മാറ്റം വരുത്താൻ കഴിയില്ല. വിവരങ്ങൾ കാണാൻ ആഗ്രഹിക്കുന്ന ഒരു ക്ലയന്റിനോ ഓഡിറ്റർക്കോ അല്ലെങ്കിൽ കാണാൻ മാത്രം ആവശ്യമുള്ള ഒരു പങ്കാളിക്കോ അനുയോജ്യമായ അനുമതി.

നിങ്ങളുടെ ടീമിന് രഹസ്യമായി ദുർബലപ്പെടുത്താൻ കഴിയാത്ത സൈൻ-ഇൻ

നിങ്ങൾ ആക്‌സസ് ഡെലിഗേറ്റ് ചെയ്യുന്ന അക്കൗണ്ടുകൾ പിടിച്ചെടുക്കാൻ പ്രയാസമാണെങ്കിൽ മാത്രമേ ആക്‌സസ് ഡെലിഗേറ്റ് ചെയ്യുന്നത് സുരക്ഷിതമാകൂ. അക്കൗണ്ടിലുള്ള ഓരോ വ്യക്തിക്കും, എല്ലാ പ്ലാറ്റ്‌ഫോമിലും Keycloak വഴിയാണ് പ്രാമാണീകരണം നടക്കുന്നത്.

  • ഫിഷിംഗ്-പ്രതിരോധ സൈൻ-ഇന്നിനായി പാസ്‌കീകളും WebAuthn-ഉം, ഒപ്പം പോളിസി വഴി എല്ലാവർക്കും നിർബന്ധമാക്കിയിട്ടുള്ള TOTP ടു-ഫാക്ടർ ഓതന്റിക്കേഷനും — ഒരു ടീം അംഗത്തിന് ഒഴിവാക്കാൻ കഴിയുന്ന ഐച്ഛിക ക്രമീകരണമല്ല ഇത്.
  • ഡിഫോൾട്ടായി മാജിക്-ലിങ്ക് ഇമെയിൽ സൈൻ-ഇൻ, പകരമായി ഇമെയിലും പാസ്‌വേഡും, ഒപ്പം Google, Microsoft, GitHub എന്നിവയും മറ്റുള്ളവയും വഴിയുള്ള സോഷ്യൽ സൈൻ-ഇൻ.
  • എന്റർപ്രൈസ്, ഏജൻസി ഉപഭോക്താക്കൾക്കായുള്ള SAML സിംഗിൾ സൈൻ-ഓൺ, അതിനാൽ പുതിയതായി ചേരുന്നവരെയും പോകുന്നവരെയും കൈകാര്യം ചെയ്യുന്നത് നേരിട്ടല്ലാതെ നിങ്ങളുടെ ഐഡന്റിറ്റി പ്രൊവൈഡർ വഴിയാണ്.
  • ഉപഭോക്തൃ ഡാഷ്‌ബോർഡ്, പബ്ലിക് സൈറ്റ്, നോളജ് ബേസ്, സപ്പോർട്ട് ടിക്കറ്റുകൾ എന്നിവയിലുടനീളം ഒരു സെഷൻ — ഒരിക്കൽ സൈൻ ഇൻ ചെയ്യുക, ഒരിക്കൽ അസാധുവാക്കുക.
  • സെഷൻ നയങ്ങൾ, നിർണായക പ്രവർത്തനങ്ങളിലെ സ്റ്റെപ്പ്-അപ്പ് പ്രാമാണീകരണം, ഒപ്പം അറിയപ്പെടുന്ന നെറ്റ്‌വർക്കുകളിലേക്ക് മാത്രം പ്രവേശനം പരിമിതപ്പെടുത്താൻ ആഗ്രഹിക്കുന്ന അക്കൗണ്ടുകൾക്കായി ഓർഗനൈസേഷൻ അടിസ്ഥാനത്തിലുള്ള ഓപ്ഷണൽ IP അനുവദനീയ ലിസ്റ്റുകൾ.
  • ഒരു അക്കൗണ്ട് നിലവിൽ വരുന്നതിന് മുമ്പ് തന്നെ ഓരോ സൈൻഅപ്പ് ഇമെയിലും സാധൂകരിക്കപ്പെടുന്നു, അതിനാൽ ഡെലിവറി ചെയ്യാനാവാത്തതും ഡിസ്പോസിബിളും റോൾ അധിഷ്ഠിതവുമായ വിലാസങ്ങൾ പിന്നീട് അനാഥ അംഗങ്ങളായി മാറുന്നതിന് പകരം തുടക്കത്തിൽ തന്നെ തടയപ്പെടുന്നു.

ഞങ്ങളുടെ ടീമിന് ആക്സസ് ആവശ്യമുള്ളപ്പോൾ, അത് പരിമിതമായ പരിധിയിലുള്ളതും രേഖപ്പെടുത്തപ്പെടുന്നതുമാണ്

പിന്തുണ പ്രവർത്തനങ്ങൾക്ക് ചിലപ്പോൾ നിങ്ങളുടെ അക്കൗണ്ടിനുള്ളിലേക്ക് പരിശോധിക്കേണ്ടി വരാറുണ്ട്. മറ്റെല്ലാ കാര്യങ്ങളെയും പോലെ അതേ അനുമതി മാതൃക തന്നെയാണ് ആ ആക്‌സസ്സും നിയന്ത്രിക്കുന്നത് — ചുരുങ്ങിയ അനുമതികളുള്ള വകുപ്പുകളായി തിരിച്ചിട്ടുള്ള ഒരു സ്റ്റാഫ് ഓർഗനൈസേഷനിലാണ് ജീവനക്കാർ ഉൾപ്പെടുന്നത്.

വകുപ്പുകൾ, പൂർണ്ണ അഡ്മിനല്ല

ജീവനക്കാരെ സപ്പോർട്ട്, ബില്ലിംഗ് ആൻഡ് ഫിനാൻസ്, അബ്യൂസ് ആൻഡ് ട്രസ്റ്റ്-ആൻഡ്-സേഫ്റ്റി, സെയിൽസ്, ഓൺബോർഡിംഗ്, എഞ്ചിനീയറിംഗ് ആൻഡ് ഓപ്‌സ്, മാർക്കറ്റിംഗ്, മാനേജ്‌മെന്റ് എന്നിങ്ങനെ തിരിച്ചിരിക്കുന്നു. ഓരോ റോളും നിർദ്ദിഷ്ട മൊഡ്യൂളുകളും പ്രവർത്തനങ്ങളും അനുവദിക്കുന്നു, അതിനാൽ ഒരു ഏജന്റിന് അവരുടെ ജോലിക്ക് ആവശ്യമുള്ള അഡ്മിൻ കൺസോളിന്റെ ഭാഗം മാത്രമേ കാണാനാകൂ, ബാക്കിയുള്ളവയല്ല.

ഒരു സപ്പോർട്ട് ഏജന്റിന്റെ യഥാർത്ഥ പരിധി

Support Agent റോൾ കൃത്യമായി നൽകുന്നത് ഇവയാണ്: ഉപഭോക്താക്കളെ കാണുക, ടിക്കറ്റുകൾ കാണുകയും മറുപടി നൽകുകയും ചെയ്യുക, സൈറ്റുകൾ കാണുക, ഒരു സൈറ്റ് പുനരാരംഭിക്കുകയും അതിന്റെ കാഷെ ശൂന്യമാക്കുകയും ചെയ്യുക. ഇതിൽ ബില്ലിംഗ് കോൺഫിഗറേഷനോ റീഫണ്ടുകളോ പ്ലാൻ എഡിറ്റിംഗോ ഫ്ലീറ്റ് മാനേജ്‌മെന്റോ ഉൾപ്പെടുന്നില്ല. ഒരു ഏജന്റിന് ചെയ്യാൻ കഴിയുന്ന പരിഹാര നടപടികൾ നിർണ്ണയിക്കുന്നത് റോൾ ആണ്, സദുദ്ദേശ്യമല്ല.

ഉപഭോക്താവായി സൈൻ ഇൻ ചെയ്യുന്നത് കർശനമായി നിയന്ത്രിച്ചിരിക്കുന്നു

customer.impersonate അനുമതി Manager റോളിൽ ഉൾപ്പെടുന്നില്ല — ഇത് Super Admin-ന് മാത്രമേ ഉള്ളൂ. നിങ്ങളുടെ പേരിൽ ഒരു സെഷൻ പ്രവർത്തിക്കുമ്പോൾ, ആരാണ് പ്രവർത്തിക്കുന്നത് എന്നതിൽ ഒരിക്കലും അവ്യക്തത ഉണ്ടാകാതിരിക്കാൻ ഡാഷ്‌ബോർഡിൽ സ്ഥിരമായ ഒരു ആൾമാറാട്ട ബാനർ പ്രദർശിപ്പിക്കുന്നു.

വിശേഷാധികാരമുള്ളവയെല്ലാം രേഖപ്പെടുത്തിയിട്ടുണ്ട്

ഓരോ പ്രിവിലേജ്ഡ്, അഡ്മിനിസ്ട്രേറ്റീവ് പ്രവർത്തനങ്ങളും ആക്ടർ, പ്രവർത്തനം, ടാർഗെറ്റ്, അനുബന്ധ മെറ്റാഡാറ്റ, IP വിലാസം, ടൈംസ്റ്റാമ്പ് എന്നിവ രേഖപ്പെടുത്തുന്ന, കൂട്ടിച്ചേർക്കലുകൾ മാത്രം സാധ്യമായ (append-only) ഒരു ഓഡിറ്റ് ലോഗിലേക്ക് ചേർക്കപ്പെടുന്നു — പ്രൊഡക്ഷനിൽ ഇത് സമയക്രമം അനുസരിച്ച് തരംതിരിച്ചിരിക്കുന്നു. ഉടമകൾക്കും റീഡ്-ഓൺലി അംഗങ്ങൾക്കും അവരുടെ ഓർഗനൈസേഷന്റെ ലോഗ് സ്വയം വായിക്കാനാകും.

നശീകരണ സ്വഭാവമുള്ള പ്രവൃത്തികൾക്കുള്ള അംഗീകാര ഘട്ടങ്ങൾ

ജീവനക്കാരുടെ സെൻസിറ്റീവും വിനാശകരവുമായ നടപടികൾ നടപ്പിലാക്കുന്നതിന് മുമ്പ് കൂടുതൽ ഘട്ടങ്ങളുള്ള പ്രാമാണീകരണമോ രണ്ട് വ്യക്തികളുടെ അംഗീകാരമോ ആവശ്യപ്പെടാം, കൂടാതെ പുതിയ ഡിപ്പാർട്ട്‌മെന്റുകളും റോളുകളും കോഡ് മാറ്റത്തിന് പകരമായി കോൺഫിഗറേഷനിലൂടെ സാധ്യമാകുന്നതാണ്.

മെഷീനുകൾക്കും ഡെലിഗേറ്റഡ് ആക്സസ് ലഭിക്കും

സ്ക്രിപ്റ്റുകൾ, സിഐ പൈപ്പ്‌ലൈനുകൾ, സിഎൽഐ, ടെറാഫോം പ്രൊവൈഡർ, എഐ ഏജന്റുകൾ എന്നിവയെല്ലാം ആളുകളെപ്പോലെ തന്നെ ഒരേ അനുമതി മാതൃകയിലൂടെ പ്രാമാണീകരിക്കുന്നു — പങ്കിട്ട മനുഷ്യ ക്രെഡൻഷ്യലുകളോ, ഒരു ബിൽഡിലേക്ക് പകർത്തി ഒട്ടിച്ച ദീർഘകാല രഹസ്യങ്ങളോ ഇല്ല.

API കീകൾ ഓർഗനൈസേഷൻ അടിസ്ഥാനത്തിലുള്ളതും നിർദ്ദിഷ്ട വ്യാപ്തിയുള്ളതുമാണ്

കീകൾ ഒരു ഓർഗനൈസേഷന്റെ ഉടമസ്ഥതയിലുള്ളതാണ്, കൂടാതെ ഒരേ RBAC അനുമതികളുമായി ബന്ധിപ്പിച്ചിട്ടുള്ള കൃത്യമായ വ്യാപ്തികൾ വഹിക്കുന്നു — വായിക്കാൻ മാത്രം, ബില്ലിംഗ്, പ്രൊവിഷനിംഗ്. ഒരു അംഗത്തിന്റെ മുഴുവൻ അക്കൗണ്ടിനും പകരം പൈപ്പ്‌ലൈനിന് ആവശ്യമായ പരിമിതമായ വ്യാപ്തി മാത്രം നൽകുക.

സാൻഡ്‌ബോക്സ് കീകൾ പ്രൊഡക്ഷനിൽ നിന്ന് വേറിട്ടതാണ്

ടെസ്റ്റ്-മോഡ്, ലൈവ്-മോഡ് കീകൾ വ്യത്യസ്‌തമാണ്, അതിനാൽ വികസനത്തിലുള്ള ഒരു ഇന്റഗ്രേഷന് അബദ്ധത്തിലോ പകർത്തിയ എൻവയോൺമെന്റ് വേരിയബിൾ വഴിയോ പ്രൊഡക്ഷൻ ഡാറ്റയിലേക്ക് ആക്‌സസ് ചെയ്യാൻ കഴിയില്ല.

ഹാഷ് മാത്രമേ സംഭരിക്കപ്പെടുന്നുള്ളൂ

ഞങ്ങൾ രഹസ്യ വിവരത്തിന്റെ ഒരു SHA-256 ഹാഷും ലുക്കപ്പ് പ്രിഫിക്സും മാത്രമാണ് സംഭരിക്കുന്നത് — ഒരിക്കലും റോ കീ സംഭരിക്കില്ല. നിർമ്മാണ വേളയിൽ നിങ്ങൾക്ക് കീ ഒരിക്കൽ മാത്രമേ കാണാൻ സാധിക്കൂ. ഓരോ കീയും അത് അവസാനം ഉപയോഗിച്ചത് എപ്പോഴാണെന്ന് ട്രാക്ക് ചെയ്യുന്നു, കൂടാതെ മറ്റൊന്നിനെയും ബാധിക്കാതെ തന്നെ ഇത് മാത്രമായി റദ്ദാക്കാനും കഴിയും.

AI ടൂളുകൾ നിങ്ങളുടെ അനുമതികൾക്ക് കീഴിൽ ബന്ധിപ്പിക്കുന്നു

ഞങ്ങളുടെ MCP സെർവർ ഏത് MCP-പ്രാപ്തമാക്കിയ ഏജന്റിനും സ്വാഭാവിക ഭാഷയിൽ നിങ്ങളുടെ ഹോസ്റ്റിംഗ് മാനേജ് ചെയ്യാൻ അനുവാദം നൽകുന്നു; ഇത് OAuth 2.1 ഉപയോഗിച്ച് ആധികാരികത ഉറപ്പാക്കിയതും, നിങ്ങളുടെ സ്ഥാപനത്തിനും RBAC റോളിനും പരിമിതപ്പെടുത്തിയതും, ഓരോ ടൂളിനും അസാധുവാക്കാവുന്ന ടോക്കണുകൾ, വിനാശകരമായ പ്രവർത്തനങ്ങളിലെ സ്ഥിരീകരണം, ചെലവ് പരിധികൾ, പൂർണ്ണമായ ഓഡിറ്റ് ലോഗിംഗ് എന്നിവയോടുകൂടിയതുമാണ്.

സൈറ്റുകളിലേക്ക് തന്നെയുള്ള ആക്സസ്

അക്കൗണ്ട് ആക്‌സസ്സും സെർവർ ആക്‌സസ്സും വ്യത്യസ്തമായ പ്രശ്നങ്ങളാണ്. സൈറ്റ്-ലെവൽ ക്രെഡൻഷ്യലുകൾ ഡാഷ്‌ബോർഡിൽ മാനേജ് ചെയ്യപ്പെടുന്നു, ഏറ്റവും കുറഞ്ഞ പ്രിവിലേജോടെ നൽകപ്പെടുന്നു, കൂടാതെ ഒരു സഹകാരിയുടെ ഷെൽ ഒരു സൈറ്റിന്റെ ഷെൽ മാത്രമായിരിക്കാൻ വിധം ഐസൊലേറ്റ് ചെയ്യപ്പെടുന്നു.

  • ജയിൽഡ് ഷെല്ലോടുകൂടിയ SSH, ഒപ്പം SFTP-യും FTP-യും — CageFS ഐസൊലേഷൻ വഴി ഓരോ ഉപയോക്താവിനും അവരുടെ സ്വന്തം ഫയലുകൾ മാത്രമേ കാണാനാകൂ.
  • ഡെവലപ്പർമാർ യഥാർത്ഥത്തിൽ സ്ക്രിപ്റ്റ് ചെയ്യാൻ ആഗ്രഹിക്കുന്ന പ്രവർത്തനങ്ങൾക്കായി, പാനൽ ടെർമിനലിൽ നിന്നും SSH വഴിയുമുള്ള wp-cli.
  • code-server വഴി ബ്രൗസറിൽ പൂർണ്ണമായ ഒരു VS Code എഡിറ്റർ, git സഹിതം, ഡാഷ്‌ബോർഡിൽ നിന്ന് നേരിട്ട് സൈറ്റിന്റെ ഫയലുകൾ എഡിറ്റ് ചെയ്യുന്നു.
  • ഡാറ്റാബേസുകൾക്കായുള്ള എംബഡഡ് phpMyAdmin, Adminer എന്നിവയും, ഒരു എംബഡഡ് ഫയൽ മാനേജരും; ഇവ രണ്ടും മറ്റൊരു ലോഗിൻ വിവരങ്ങൾ ആവശ്യപ്പെടുന്നതിന് പകരം ഡാഷ്‌ബോർഡിൽ നിന്ന് സിംഗിൾ സൈൻ-ഓൺ വഴി ആക്‌സസ് ചെയ്യാവുന്നതാണ്.
  • ആക്സസ് കീകൾ, ക്രെഡൻഷ്യലുകൾ എന്നിവ ഡാഷ്‌ബോർഡിൽ സൃഷ്‌ടിക്കുകയും ലിസ്റ്റ് ചെയ്യുകയും റൊട്ടേറ്റ് ചെയ്യുകയും അസാധുവാക്കുകയും ചെയ്യുന്നു, ഏറ്റവും കുറഞ്ഞ പ്രിവിലേജോടെ നൽകുന്നു, ഒപ്പം അവയുടെ ഉപയോഗം ഓഡിറ്റ്-ലോഗ് ചെയ്യപ്പെടുന്നു.
  • ക്ലോണും പുഷ്-ടു-ലൈവും ഉള്ള സ്റ്റേജിംഗ് അപകടസാധ്യതയുള്ള ജോലികളെ പ്രൊഡക്ഷനിൽ നിന്ന് മാറ്റിനിർത്തുന്നു, അതിനാൽ ഒരു പുതിയ സഹപ്രവർത്തകന്റെ ആദ്യ മാറ്റം ഒരിക്കലും നേരിട്ട് ഒരു ലൈവ് സൈറ്റിലേക്ക് എത്തുന്നില്ല.

നിങ്ങളുടെ യഥാർത്ഥ പ്രവർത്തനരീതിക്ക് അനുയോജ്യമായ രീതിയിൽ ആക്സസ് എങ്ങനെ ക്രമീകരിക്കാം

ഒരു സോളോ ഓപ്പറേറ്റർ ഒരൊറ്റ ഓർഗനൈസേഷനും ഒരു ഓണർ അംഗത്വവും നിലനിർത്തുന്നു, കൂടാതെ ഒരു പ്രോജക്റ്റിനായി ഒരു കരാറുകാരൻ വരുമ്പോൾ ഒരു ഡെവലപ്പർ റോൾ ചേർക്കുകയും ചെയ്യുന്നു. പ്രോജക്റ്റ് അവസാനിക്കുമ്പോൾ, അംഗത്വം നീക്കംചെയ്യപ്പെടുകയും അവരുടെ സൈൻ-ഇൻ ഉടനടി പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്നു — മാറ്റിസ്ഥാപിക്കാൻ പങ്കിട്ട ക്രെഡൻഷ്യലുകളൊന്നും അവശേഷിക്കുന്നില്ല.

ഒരു ഏജൻസി ഓർഗനൈസേഷൻ ട്രീ ഉപയോഗിക്കുന്നു. ഓരോ ക്ലയന്റിനും അവരുടെ സൈറ്റുകൾ ഉൾക്കൊള്ളുന്ന സ്വന്തം ചൈൽഡ് ഓർഗനൈസേഷൻ ലഭിക്കുന്നു, കൂടാതെ ക്ലയന്റിന്റെ ആളുകൾക്ക് അവിടെ അംഗത്വങ്ങളും ലഭിക്കുന്നു — പ്രവർത്തനങ്ങൾ നിരീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്ന പങ്കാളികൾക്ക് റീഡ്-ഒൺലി ആക്സസും, സ്വയം സേവനം ആഗ്രഹിക്കുന്ന ക്ലയന്റിന് ഉടമസ്ഥാവകാശവും. നിങ്ങളുടെ ജീവനക്കാർ ട്രീയിലെ ഉയർന്ന തലങ്ങളിൽ അംഗത്വങ്ങൾ വഹിക്കുകയും പോർട്ട്ഫോളിയോ കാണുകയും ചെയ്യുന്നു; എന്നാൽ ഒരു ക്ലയന്റ് അവരുടെ സ്വന്തം ബ്രാഞ്ച് മാത്രമേ കാണുന്നുള്ളൂ, Row-Level Security വെറുമൊരു വാഗ്ദാനത്തിനപ്പുറം ഇതിനെ യാഥാർത്ഥ്യമാക്കുന്നു.

ഒരു റീസെല്ലറും ഇതേ രീതിയിൽ തന്നെയാണ് പ്രവർത്തിക്കുന്നത്, ഒരു തലം കൂടി മുകളിലാണെന്ന് മാത്രം: ഒരു റീസെല്ലർ ഓർഗനൈസേഷന് കീഴിൽ ക്ലയന്റ് ഓർഗനൈസേഷനുകൾ ഉണ്ടായിരിക്കും, അവയോരോന്നിനും സ്വന്തമായി അംഗങ്ങളും ബില്ലിംഗ് കാഴ്‌ചയും സൈറ്റുകളും ഉണ്ടായിരിക്കും. സബ് അക്കൗണ്ടുകൾ, ഏജൻസി ടീമുകൾ, റീസെല്ലർ ശ്രേണികൾ എന്നിവയെല്ലാം ഒരേ പ്രിമിറ്റീവ് അടിസ്ഥാനമാക്കിയാണ് പ്രവർത്തിക്കുന്നത് — ഇവയ്‌ക്കൊന്നിനും പ്രത്യേകമായതോ ദുർബലമായതോ ആയ സംവിധാനമില്ല.

കാർഡ് ആവശ്യമില്ലാത്ത 14 ദിവസത്തെ ട്രയലിൽ എല്ലാം ലഭ്യമാണ്. പേയ്‌മെന്റ് വിവരങ്ങളില്ലാതെ സൈൻ അപ്പ് ചെയ്യുക, ഒരു സഹപ്രവർത്തകനെ ക്ഷണിക്കുക, ഓരോ റോളുകൾക്കും എന്തൊക്കെ ആക്‌സസ് ചെയ്യാനാകും, എന്തൊക്കെ കഴിയില്ല എന്ന് നിരീക്ഷിക്കുക, നിങ്ങളുടെ സ്വന്തം ഓഡിറ്റ് ലോഗ് വീണ്ടും വായിച്ചുനോക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

എനിക്ക് ഒരാൾക്ക് ഒരു സൈറ്റിലേക്ക് മാത്രമായി ആക്‌സസ് നൽകാൻ കഴിയുമോ?

നിലവിൽ, ഒരു അംഗത്വം അതിന്റെ പങ്കിനെ ഒരു സ്ഥാപനത്തിലും അതിന്റെ ശ്രേണിയിലുള്ള എല്ലാത്തിലും നൽകുന്നു, അതിനാൽ സൈറ്റ് സെറ്റുകൾ വേർതിരിക്കാനുള്ള വഴി സ്ഥാപനങ്ങളെ വേർതിരിക്കുക എന്നതാണ് — ആ സൈറ്റുകളെ അവയുടെ സ്വന്തം ചൈൽഡ് സ്ഥാപനത്തിൽ ഉൾപ്പെടുത്തുകയും അംഗത്വം അവിടെ നൽകുകയും ചെയ്യുക. ഓരോ ക്ലയന്റും ഇതിനകം സ്വന്തം പരിധി ആഗ്രഹിക്കുന്ന ഏജൻസികൾക്കും റീസെല്ലർമാർക്കും ഇതൊരു മികച്ച മാതൃകയാണ്. ഒരു സ്ഥാപനത്തിനുള്ളിലെ നിർദ്ദിഷ്ട സൈറ്റുകളിലേക്ക് ഒരു അംഗത്വം മാത്രമായി പരിമിതപ്പെടുത്തുന്ന 'പ്രതി-അംഗത്വ റിസോഴ്സ് സ്കോപ്പിംഗ്', ഇപ്പോൾ ലഭ്യമായ ഒന്നല്ല, മറിച്ച് ആസൂത്രണം ചെയ്ത ഒരു മെച്ചപ്പെടുത്തലാണ്.

ഞാൻ ക്ഷണിക്കുന്ന ഒരു ഡെവലപ്പർക്ക് ഒരു സൈറ്റ് ഇല്ലാതാക്കാനോ ലൈവിലേക്ക് പുഷ് ചെയ്യാനോ കഴിയുമോ?

Developer റോളിന് സൈറ്റ് ഇല്ലാതാക്കാനോ സൈറ്റ് സസ്‌പെൻഡ് ചെയ്യാനോ ഉള്ള അധികാരമില്ല — ആ കീകൾ Owner റോളിന്റേതാണ്. സൈറ്റുകൾ കാണാനും സൃഷ്‌ടിക്കാനും സേവനങ്ങൾ പുനരാരംഭിക്കാനും കാഷെ ശൂന്യമാക്കാനും API കീകൾ നിയന്ത്രിക്കാനും ടിക്കറ്റുകളിൽ പ്രവർത്തിക്കാനുമുള്ള അനുമതി ഇത് നൽകുന്നു. ഡിപ്ലോയ്‌മെന്റും push-to-live അനുമതികളും Developer ഗ്രാൻറിന്റെ ഭാഗമല്ല, അതിനാൽ പ്രൊഡക്ഷനിലേക്കുള്ള മാറ്റം അക്കൗണ്ട് ഉടമയിൽ തന്നെ നിലനിൽക്കുന്നു. ബിൽഡ് വർക്കുകൾ തുടക്കം മുതലേ ലൈവ് സൈറ്റിന് പുറത്ത് നടക്കാൻ ഇത് സ്റ്റേജിംഗുമായി സംയോജിപ്പിക്കുക.

Zinn Digital® ജീവനക്കാർക്ക് എൻ്റെ അക്കൗണ്ടിൽ എന്തൊക്കെ കാണാൻ കഴിയും?

ഇത് ജീവനക്കാരുടെ റോളിനെ പൂർണ്ണമായും ആശ്രയിച്ചിരിക്കുന്നു, ഓരോ റോളും അനുമതി കീകളുടെ ഒരു പ്രത്യേക ഗണമാണ്. ഉദാഹരണത്തിന്, ഒരു Support Agent-ന് നിങ്ങളുടെ അക്കൗണ്ടും സൈറ്റുകളും കാണാനും, നിങ്ങളുടെ ടിക്കറ്റുകൾ കാണാനും മറുപടി നൽകാനും, ഒരു സൈറ്റ് റീസ്റ്റാർട്ട് ചെയ്യാനും അതിന്റെ കാഷെ നീക്കം ചെയ്യാനും കഴിയും — കൂടാതെ ബില്ലിംഗ് കോൺഫിഗറേഷൻ, റീഫണ്ടുകൾ, പ്ലാനുകൾ അല്ലെങ്കിൽ ഫ്ലീറ്റ് എന്നിവയിൽ മാറ്റം വരുത്താൻ കഴിയില്ല. ഒരു ഉപഭോക്താവായി സൈൻ ഇൻ ചെയ്യുന്നത് Super Admin-ന് മാത്രം കൈവശമുള്ള ഒരു പ്രത്യേക അനുമതിയാണ്, അത് സംഭവിക്കുമ്പോൾ ഡാഷ്‌ബോർഡ് സ്ഥിരമായ ഒരു ഇംപേഴ്‌സണേഷൻ ബാനർ കാണിക്കുന്നു. പ്രത്യേകാവകാശമുള്ള ഓരോ പ്രവർത്തനവും ആക്റ്റർ, പ്രവർത്തനം, ടാർഗെറ്റ്, IP, ടൈംസ്റ്റാമ്പ് എന്നിവയോടൊപ്പം ഓഡിറ്റ് ലോഗിൽ രേഖപ്പെടുത്തപ്പെടുന്നു, കൂടാതെ നിങ്ങളുടെ ഓർഗനൈസേഷന്റെ ലോഗ് നിങ്ങൾക്ക് സ്വയം വായിക്കാനും കഴിയും.

ആരെങ്കിലും പോവുകയാണെങ്കിൽ ഞാൻ എങ്ങനെയാണ് വേഗത്തിൽ ആക്സസ് അസാധുവാക്കുക?

അംഗത്വം നീക്കംചെയ്യുക, അപ്പോൾ ആ സ്ഥാപനത്തിലേക്കുള്ള അവരുടെ ആക്‌സസ് അവസാനിക്കും — അവർക്ക് സ്വന്തം ഐഡന്റിറ്റി നിലനിൽക്കുമെങ്കിലും, നിങ്ങളുടെ അക്കൗണ്ടിൽ റോളോ അതുകൊണ്ടുതന്നെ അനുമതികളോ ഉണ്ടാകില്ല. API കീകൾ വ്യക്തിഗതമായി റദ്ദാക്കപ്പെടുന്നു, അതിനാൽ മറ്റൊന്നിനെയും ബാധിക്കാതെ ഒരു പൈപ്പ്‌ലൈൻ കീ വിച്ഛേദിക്കാം. നിങ്ങൾ SAML സിംഗിൾ സൈൻ-ഓൺ ആണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, നിങ്ങളുടെ ഐഡന്റിറ്റി പ്രൊവൈഡറിലെ ഡിപ്രൊവിഷനിംഗ് സൈൻ-ഇൻ കേന്ദ്രീകൃതമായി കൈകാര്യം ചെയ്യുന്നു. SSH കീകൾ പോലുള്ള സൈറ്റ്-ലെവൽ ക്രെഡൻഷ്യലുകൾ ഡാഷ്‌ബോർഡിൽ റദ്ദാക്കപ്പെടുന്നു, ഒപ്പം നീക്കംചെയ്യൽ പ്രക്രിയ ഓഡിറ്റ് ലോഗിൽ രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു.

ടീം അംഗങ്ങൾ എന്റെ API കീകൾ പങ്കിടുന്നുണ്ടോ?

അല്ല — എന്നാൽ അതിനുള്ള കാരണം വ്യക്തമാക്കേണ്ടതുണ്ട്. API കീകൾ ഒരു വ്യക്തിഗത അംഗത്തിനല്ല, മറിച്ച് സ്ഥാപനത്തിൻ്റേതാണ്, കൂടാതെ ഒരേ അനുമതി കാറ്റലോഗുമായി ബന്ധിപ്പിച്ചിട്ടുള്ള അവയുടേതായ വിശദമായ സ്കോപ്പുകൾ അവയ്ക്കുണ്ട്. അതിനാൽ ഒരു വ്യക്തിക്ക് ഒരു കീ കൈമാറുന്നതിനുപകരം, ആ ജോലിക്ക് ആവശ്യമായ ഏറ്റവും ചുരുങ്ങിയ സ്കോപ്പോടെ അത് ചെയ്യുന്ന ജോലിക്കായി നിങ്ങൾ ഒരു കീ സൃഷ്ടിക്കുകയും ജോലി അവസാനിക്കുമ്പോൾ ആ കീ അസാധുവാക്കുകയും ചെയ്യുന്നു. രഹസ്യ വിവരത്തിന്റെ ഒരു ഹാഷ് മാത്രമേ സംഭരിക്കപ്പെടുന്നുള്ളൂ, കൂടാതെ ഓരോ കീയും അവസാനമായി എപ്പോഴാണ് ഉപയോഗിച്ചതെന്ന് രേഖപ്പെടുത്തുന്നു, അതിനാൽ ഉപയോഗിക്കാത്ത കീകൾ കണ്ടെത്താനും പിൻവലിക്കാനും എളുപ്പമാണ്.

എല്ലാത്തിലേക്കുമുള്ള കീകൾ നൽകാതെ തന്നെ എനിക്ക് ഒരു AI ഏജന്റിനെ ബന്ധിപ്പിക്കാൻ കഴിയുമോ?

അതെ. ഞങ്ങളുടെ MCP സെർവർ OAuth 2.1 ഉപയോഗിച്ച് ഏജന്റുകളെ പ്രാമാണീകരിക്കുകയും, ഓരോ ടൂളിനും റദ്ദാക്കാവുന്ന ടോക്കണുകൾ സഹിതം നിങ്ങളുടെ ഓർഗനൈസേഷനിലേക്കും നിങ്ങളുടെ RBAC റോളിലേക്കും അവയുടെ പരിധി നിശ്ചയിക്കുകയും ചെയ്യുന്നു, അതിനാൽ നിങ്ങൾക്ക് പൂർണ്ണ ആക്സസിന് പകരം ഒരു നിർദ്ദിഷ്ട ശേഷി നൽകാൻ കഴിയും. വിനാശകരമായ പ്രവർത്തനങ്ങൾക്ക് സ്ഥിരീകരണം ആവശ്യമാണ്, ചെലവ് പരിധികൾ ബാധകമാണ്, കൂടാതെ എല്ലാ പ്രവർത്തനങ്ങളും മാനുവൽ പ്രവർത്തനങ്ങളുടെ അതേ ഓഡിറ്റ് ലോഗിൽ രേഖപ്പെടുത്തപ്പെടുന്നു.

ഒരു വാടകക്കാരൻ മറ്റൊരു വാടകക്കാരന്റെ ഡാറ്റ ആക്‌സസ് ചെയ്യുന്നത് തടയുന്നത് എന്താണ്?

Postgres Row-Level Security, ആപ്ലിക്കേഷൻ-ലെവൽ ഫിൽട്ടറിനെ ഒരേയൊരു പ്രതിരോധ മാർഗ്ഗമാക്കാതെ കൂടുതൽ ആഴത്തിലുള്ള പ്രതിരോധമാക്കി മാറ്റിക്കൊണ്ട്, ഡാറ്റാബേസിൽ തന്നെയുള്ള കോളറുടെ ഓർഗനൈസേഷൻ ഉപശാഖയിലേക്ക് ക്വറികളെ പരിമിതപ്പെടുത്തുന്നു. പരിധിക്ക് പുറത്തുള്ള റെക്കോർഡുകൾക്കായുള്ള അഭ്യർത്ഥനകൾ പെർമിഷൻ പിശകിന് പകരം നോട്ട്-ഫൗണ്ട് എന്നാണ് നൽകുന്നത്, അതിനാൽ അവിടെ നിലവിലുള്ളവയെക്കുറിച്ച് ഒന്നും വെളിപ്പെടുത്തില്ല. സെർവർ ഭാഗത്ത്, CageFS വഴിയുള്ള ഓരോ സൈറ്റിന്റെയും വേർതിരിവ് ഓരോ വാടകക്കാരന്റെയും ഷെല്ലും ഫയലുകളും അവരുടെ സ്വന്തം സൈറ്റിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തുന്നു.

പണം നൽകുന്നതിന് മുൻപ് എനിക്ക് ഇത് പരീക്ഷിച്ച് നോക്കാമോ?

അതെ. 14 ദിവസത്തെ ട്രയലിന് കാർഡ് ആവശ്യമില്ല — പേയ്‌മെന്റ് വിവരങ്ങളോ ബാധ്യതകളോ ഇല്ല — കൂടാതെ അഞ്ച് സൈറ്റുകൾ വരെയുള്ള Footprint-Free ഹോസ്റ്റിംഗ് ഇതിൽ ഉൾപ്പെടുന്നു. പ്ലാൻ എടുക്കുന്നതിന് മുമ്പ് ഒരു സഹപ്രവർത്തകനെ ക്ഷണിക്കാനും റോൾ നൽകാനും അതിരുകൾ നിങ്ങളുടെ ആവശ്യാനുസരണം പ്രവർത്തിക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കാനും ഇത് മതിയാകും.

ചൂണ്ടിക്കാണിക്കാൻ കഴിയുന്ന ഒരു പരിധിയോടെ ചുമതലപ്പെടുത്തുക

കാർഡ് ആവശ്യമില്ലാത്ത 14 ദിവസത്തെ ട്രയലിലൂടെ ആരംഭിക്കൂ, മറ്റുള്ളവരെ ക്ഷണിക്കൂ, അനുമതി മാതൃക അതിന്റെ പ്രവർത്തനം എങ്ങനെ നടത്തുന്നുവെന്ന് കാണൂ — നിങ്ങൾക്ക് പേരിടാൻ കഴിയുന്ന റോളുകൾ, പിൻവലിക്കാൻ കഴിയുന്ന സ്കോപ്പുകൾ, ആര് എന്ത് ചെയ്തു എന്ന് കൃത്യമായി കാണിക്കുന്ന ഒരു ഓഡിറ്റ് ലോഗ്.

സൗജന്യമായി ആരംഭിക്കുക