„GitHub“ OAuth: rašymo leidimas gali keisti duomenis

„GitHub“ prieigos peržiūros instrukcijoje nurodytas kelias OAuth programos prieigai atšaukti: paskyros „Settings“ → „Integrations“ → „Applications“ → „Authorized OAuth Apps“. Prie nereikalingo žetono pasirinkite „Revoke“, o jei norite atšaukti visus tos programos žetonus – „Revoke all“. Prieš pasirinkdami veiksmą išsiaiškinkite, ar programa vis dar naudojama ir nuo kurio žetono priklauso jos darbas.

Ši peržiūra svarbi todėl, kad OAuth leidimas gali apimti daugiau nei prisijungimą prie paslaugos. „GitHub“ OAuth autorizavimo paaiškinime nurodyta, kad skaitymo teisė leidžia programai matyti duomenis, o rašymo teisė – juos keisti; prieigos prie šaltinio kodo šiuo metu negalima apriboti vien skaitymu. Todėl prieš atšaukdami arba palikdami integraciją vertinkite ir jos paskirtį, ir suteiktų teisių poveikį jūsų saugykloms.

Kur rasti prijungtas programas

Prisijunkite prie paskyros, kuria autorizavote integraciją. Atvėrę „Authorized OAuth Apps“, peržiūrėkite sąraše esančius žetonus ir programas. Gretima „Authorized GitHub Apps“ kortelė skirta kito tipo programoms: jei ieškomos integracijos OAuth sąraše nėra, pirmiausia įsitikinkite, kokio tipo prieigą jai suteikėte.

Pradėkite nuo paslaugų, kurių nebenaudojate, neatpažįstamų pavadinimų ir integracijų, prijungtų ankstesniam projektui. Sutikrinkite programos kūrėją su paslauga, kuriai sąmoningai leidote naudoti paskyrą. Jei integracija aptarnauja bendrą projektą, vien jūsų naudojimo istorijos nepakanka: ji gali būti reikalinga komandos procesui, nors patys jos seniai neatvėrėte.

Ką iš tikrųjų leidžia „scope“

OAuth „scope“ apibrėžia žetono prieigos apimtį. „GitHub“ OAuth leidimų sąraše „repo“ apima viešų ir privačių saugyklų kodą bei jo skaitymą ir keitimą, o „public_repo“ riboja prieigą viešomis saugyklomis, bet taip pat leidžia keisti jų kodą. Taigi žodis „viešos“ nusako saugyklų apimtį, o ne vien skaitymo teisę.

Kiti leidimai apima siauresnius veiksmus. „repo:status“ suteikia teisę skaityti ir rašyti įsipareigojimų būsenas viešose bei privačiose saugyklose, tačiau nesuteikia prieigos prie jų kodo. „user:email“ leidžia skaityti paskyros el. pašto adresus, o „read:org“ – organizacijos narystės, komandų narystės ir projektų duomenis. Atskirai įvertinkite plačius leidimus, tokius kaip „admin:org“: jie svarbūs net tada, kai programa tiesiogiai nekeičia kodo.

Vertinkite visą žetonui suteiktų leidimų rinkinį, o ne vien programos pavadinimą ar pirminį jos prašymą. Naudotojas gali suteikti mažiau teisių, nei programa prašė, ir vėliau jas pakeisti. Kartu „scope“ nesuteikia programai daugiau galių, nei turite jūs: jei negalite keisti konkrečios saugyklos, jūsų žetonas tos teisės programai nesukuria. Jei galite ją keisti, rašymo leidimas tampa reikšminga prieiga, kurią verta pagrįsti dabartiniu poreikiu.

Kada prieiga paliečia organizaciją

Asmeninėje paskyroje autorizuota OAuth programa gali turėti poveikį ir organizacijos ištekliams. Jei organizacija taiko OAuth programų prieigos apribojimus, programai pasiekti jos neviešus išteklius reikia savininko patvirtinimo; nepatvirtinta programa gali pasiekti tik viešus organizacijos išteklius. Kai tokių apribojimų nėra, asmeninėje paskyroje autorizuota programa automatiškai gauna prieigą prie organizacijos išteklių tiek, kiek leidžia jūsų teisės ir žetono „scope“.

Jei priklausote kelioms organizacijoms, prie kiekvienos integracijos pasižymėkite, kurioje iš jų ji naudojama. Ypač svarbu atskirti asmenines saugyklas nuo organizacijos privačių saugyklų ir nustatyti, kas atsakingas už integraciją. Šis patikrinimas padeda priimti sprendimą dėl reikalingos komandos automatizacijos, o neatpažįstamą prieigą leidžia nagrinėti pagal konkretų jos poveikį.

Trumpa kiekvienos programos audito lentelė

Kiekvienai programai skirkite atskirą lentelės eilutę. Tuos pačius klausimus taikykite ir asmeniniam įrankiui, ir komandos integracijai, kad sprendimas priklausytų nuo suteiktos prieigos bei dabartinio poreikio:

Programa ir kūrėjas. Įrašykite pavadinimą, kūrėją ir paslaugą, su kuria siejate autorizavimą. Jei ryšio neatpažįstate, taip ir pažymėkite.
Naudojimo poreikis. Nurodykite paskutinį jums žinomą realų naudojimą ir darbą, kuriam programa dabar reikalinga. Nežinomos datos nepaverskite spėjimu.
Saugyklų apimtis. Atskirai pažymėkite viešas ir privačias saugyklas, taip pat asmeninius bei organizacijų projektus, kuriuos programa gali pasiekti.
Veiksmų teisės. Užrašykite, ką žetonas gali skaityti ir ką gali keisti. Prie plačių „repo“ ar organizacijos valdymo leidimų nurodykite konkretų jų poreikį.
Organizacijų poveikis. Įvardykite komandą arba proceso savininką, su kuriuo reikia suderinti bendros integracijos išjungimą.
Sprendimas. Įrašykite „palikti“, „atšaukti“ arba „patikslinti poreikį“ ir trumpą priežastį. Jei poreikį tikslinsite, nurodykite, kas gali į jį atsakyti.

Programa, kurios paskirtis pasibaigė, neturėtų likti vien todėl, kad anksčiau buvo patogi. Jei ji būtina, bet turi platesnes teises, nei tikėjotės, išsiaiškinkite, kuriam veiksmui tos teisės reikalingos ir ar paslauga gali veikti su siauresne prieiga. Taip atskirsite pagrįstą darbo priklausomybę nuo senos autorizacijos, kuriai nebėra aiškaus savininko.

Atšaukite prieigą ir patikrinkite priklausomybes

Prieš pasirinkdami „Revoke“ arba „Revoke all“, nustatykite, ar ta pati programa naudojama prisijungti prie paslaugos, vykdyti automatines užduotis arba skelbti būsenas saugykloje. Atskiro žetono atšaukimas ir visų programos žetonų atšaukimas skiriasi apimtimi, todėl pasirinkimą siekite su tuo, kokią prieigą iš tiesų norite nutraukti. Bendros integracijos atveju apie numatomą veiksmą informuokite jos proceso savininką.

Po atšaukimo atlikite darbą, kuriam integracija buvo naudojama, ir patikrinkite susijusių automatizacijų būseną. Jei būtinas procesas sustojo, nustatykite, kuriam žingsniui trūksta prieigos, prieš iš naujo autorizuodami programą. Naujo autorizavimo metu įvertinkite prašomas teises ir organizacijų poveikį, o audito lentelėje užfiksuokite galutinį sprendimą bei jo priežastį.

Taip pat skaitykite: