ደህንነት

ማረጋገጫ

መለያዎች በ Supabase Auth በኢሜይልና ይለፍ ቃል፣ Google OAuth፣ ወይም GitHub OAuth ይተዳደራሉ። ከገቡ በኋላ፣ አሳሽዎ በመድረክ middleware በራስ-ሰር የሚያድስ session token (JWT) ይይዛል፣ ስለዚህ የሚሰራ session በስራ መካከል በጸጥታ አይጠፋም።

API ያንን session token በሁለት ዓይነት ይቀበላል: dashboard እንዲያውም እንደሚልከው session cookie ወይም Authorization Bearer header ሆኖ። ያለ ብራውዘር login ያለ programmatic access ይልቁን ከታች እንደተገለጸው API keys ይጠቀማል። Endpoint ዎች ያለ ትክክለኛ credential ጥያቄዎችን ውድቅ ያደርጋሉ፤ በግልጽ የህዝብ የሆኑ routes ብቻ፣ እንደ health check እና contact form፣ ያለ ማረጋገጫ ይሰራሉ።

ሚናዎችና ፈቃዶች

እያንዳንዱ መለያ በትክክል አንድ ሚና አለው: CLIENT, OPERATOR, ወይም ADMIN። ደንበኞች ሮቦቶችን ይይዛሉ ለክፍለ ጊዜዎችም ይከፍላሉ፣ ኦፕሬተሮች ሮቦቶችን ያንቀሳቅሳሉ ከክፍለ ጊዜዎችም ገቢ ያገኛሉ፣ አድሚን ደግሞ መድረኩን ያስተዳድራል። በ onboarding ጊዜ በደንበኛና ኦፕሬተር መካከል ይመርጣሉ፤ የ admin ሚና በመድረክ አስተዳዳሪዎች ይመደባል በራስ-ተመዘንም ሊመረጥ አይችልም።

የሚና ምርመራዎች በእያንዳንዱ ጥያቄ ላይ server-side ይከናወናሉ፣ በ UI ውስጥ አይደለም። Under the API ደግሞ database access በ row-level security policies ተጨማሪ የተገደበ ነው፣ ስለዚህ በ endpoint ውስጥ ያለ bug እንኳ ወደ ሌሎች መለያዎች ረድፎች ነጻ ተደራሽነት አይቀየርም።

API Keys

API keys ያለ ብራውዘር login ለ scripts እና servers ተደራሽነት ይሰጣሉ። በ /dashboard/settings ውስጥ ይፈጥሯቸዋል ይሰርዟቸውማል፤ keys ayr_live_ prefix ይይዛሉ እንደ Authorization Bearer header ም ይላካሉ። Key ውን በፈጠረው መለያ ሚናና ፈቃድ ይሰራል፣ ስለዚህ የሚፈስ key በትክክል እንደ ሚፈስ ይለፍ ቃል መጥፎ ነው።

• Key ዎችን server-side ያቆዩ። በ client-side JavaScript፣ በ mobile apps፣ ወይም በ public repositories ውስጥ አይገባቸውም።
• ለእያንዳንዱ integration አንድ key ይጠቀሙ። የሆነ ነገር ቢፈስ፣ አንድ ተጠቃሚ መሰረዝ ይፈልጋሉ፣ ሁሉንም አይደለም።
• ያለ downtime ይቀያይሩ: መጀመሪያ ተለዋጭ key ይፍጠሩ፣ deploy ያድርጉት፣ ከዚያም አሮጌውን key በ /dashboard/settings ውስጥ ይሰርዙ።
• በማንኛውም ጥርጣሬ ወዲያውኑ ይሰርዙ። አዲስ key መፍጠር ሰከንዶች ያስከፍላል፤ ትክክለኛ key ያለው ጥቃት አድራሽ መለያዎ ማድረግ የሚችለውን ማንኛውንም ነገር ማድረግ ይችላል።

ቀጥታ ቁጥጥር ወቅት ያሉ ጥበቃዎች

ቀጥታ ቁጥጥር ከ session lease ጋር የተያያዘ ነው። ሮቦት ትዕዛዞችን የሚቀበለው በትክክል በአንድ ACTIVE ክፍለ ጊዜ ውስጥ ብቻ በሚሆንበት ጊዜ ነው፣ ያንን ክፍለ ጊዜ ከያዘው ኦፕሬተር ብቻ፤ ሮቦቱ ራሱ ለሌላው ሁሉ IN_SESSION ተብሎ ይሰየማል። ኦፕሬተር በአንድ ጊዜ ቢበዛ አንድ ACTIVE ወይም PAUSED ክፍለ ጊዜ ብቻ ሊይዝ ይችላል፣ ይህም አንድ ሰው በስም ሁለት እጆችን በአንድ ጊዜ ከመቆጣጠር ያስቀራል።

Cockpit እጁን ወዲያውኑ የሚያቆም የአደጋ ማቆሚያ ይሰጣል፣ ክፍለ ጊዜውን ማቆም ወይም ማጠናቀቅም የትዕዛዝ ፍሰትን በጠቅላላ ያቆማል። በተጨማሪ፣ መድረኩ የኦፕሬተር እንቅስቃሴን ይከታተላል: ያለ ግቤት ጊዜ ካለፈ በኋላ የእንቅስቃሴ ማነስ ማስጠንቀቂያ ይላካል፣ ኦፕሬተሩ እንቅስቃሴ ማጣት ከቀጠለም ክፍለ ጊዜው በራስ-ሰር ይቆማል። ያ ሁለቱንም ወገኖች ይጠብቃል፣ ደንበኛውን ስራ ላልተሰራ ጊዜ ከመክፈል ሮቦቱንም ቀጥታ lease ባለው ቁጥጥር-አልባ ሁኔታ ውስጥ ከመቀመጥ።

Audit Trail

እያንዳንዱ ክፍለ ጊዜ የክስተት log ይይዛል: መጀመሪያና መጨረሻ፣ ማቆምና መቀጠል፣ የእንቅስቃሴ ምርመራዎች፣ የእንቅስቃሴ ማነስ ማስጠንቀቂያዎች፣ የኦፕሬተር ልውውጦች፣ የማራዘሚያ ጥያቄዎች፣ ስህተቶች፣ እያንዳንዱም የጊዜ ማህተም ጋር። ክርክር ሲገመገም፣ ይህ የክስተት log ዋና ማስረጃ ነው፣ ይህም መድረኩ በራስ-ሰር የሚጽፍበት አንድ ተጨማሪ ምክንያት ነው በማንም ሰው ትውስታ ላይ ከመተማመን ይልቅ።

ከክፍለ ጊዜዎች ውጭ፣ ጠቃሚ የመድረክ ድርጊቶች ከድርጊቱ ፈጻሚ ተጠቃሚ id፣ ድርጊቱ፣ የተነካው resource፣ metadata ጋር በ audit log ውስጥ ይመዘገባሉ። የመገለጫ ለውጦች፣ ከክፍያ ጋር ተዛማጅ ግብይቶች፣ የ admin ድርጊቶች ሁሉም entries ይተዋሉ። Audit records በመድረኩ ይጻፋሉ በማንኛውም ተጠቃሚ-ፊት ገጽ በኩልም ሊስተካከሉ አይችሉም።

Encryption ና የዳታ ጥበቃ

ወደ መድረኩና ከመድረኩ ያለ trafic ሁሉ በ transit ውስጥ በ TLS encrypted ነው፣ የቪዲዮ streams ና የቁጥጥር ምልክቶችን ጨምሮ። በ data layer፣ row-level security policies database access ን ለእያንዳንዱ መለያ ይገድባል። የክፍያ ዳታ ከሁሉም በጣም ግልጽ ድንበር ነው: ካርድና የባንክ ዝርዝሮች በ Stripe ብቻ ይያዛሉ በ AY-Robots servers በፍጹምም አይነኩም።

ተጋላጭነት ማሳወቅ

የደህንነት ችግር ካገኙ፣ /security ገጽ ወይም /contact ቅጹን Bug Report category ን በመጠቀም በሃላፊነት ያሳውቁ። ያገኙትን፣ የት እንደሆነ፣ እንዴት እንደገና ማምጣት እንደሚቻልም ያካትቱ፤ ችግሩን ለማሳየት ከሚያስፈልገው ዝቅተኛ ደረጃ ውጭ የሌሎች ተጠቃሚዎችን ዳታ አይድረሱ፣ ምክንያታዊ እድል ሰጥተን እስክናስተካክለው ድረስም ዝርዝሮችን አያትሙ። እያንዳንዱን ሪፖርት እናነባለን።

በተደጋጋሚ የሚጠየቁ ጥያቄዎች