Товлосон ажил эсвэл хүний нэвтрэлт: API аль таних тэмдгийг харах ёстой вэ?

Товлосон ажил болон нэвтрэх цонхны өмнө зогсож буй хүн нэг API-г өөр өөр итгэмжлэлээр, өөр өөр амьдрах хугацаатай, өөр өөр эзэмшигчтэй дууддаг. Ажилд сүлжээний зам, програмын таних тэмдэг, зөвшөөрлийн багц хэрэгтэй; хүнд нэвтрэлт, хоёр дахь хүчин зүйл, сесс хэрэгтэй. Хоёрыг холих нь хүний нууц үг солигдох бүрт эвдэрдэг автоматжуулалт, эсвэл cron ажлыг амьд байлгахын тулд яг төдий л сулруулсан олон хүчин зүйлийн бодлого үүсгэдэг.

Нэг мэт харагдах гурван хаалга

Эх сурвалжийн хаягийн дүрэм хүсэлт хаанаас ирснийг асуудаг. Баталгаажуулалт хэн дуудаж байгаа, ямар нотолгоо гаргасныг асуудаг. Зөвшөөрөл нь энэ субъект энэ үйлдлийг хийж болох эсэхийг асуудаг. VPN гурвын эхнийхийг л өөрчилдөг бөгөөд ажилд төдийгүй хост дээрх процес бүрд өөрчилдөг тул ослын бүртгэлд гурван ажиглалтыг тусгаарлаж хадгална уу.

Тиймээс гарах зангилааг солих нь эх сурвалжийн хаягийн улмаас үүссэн татгалзлыг засч, хүчингүй токеныг хөндөхгүй орхиж чадна. Тиймээс хүчинтэй API токен нь тийшээ замгүй ажлаас хувийн төгсгөлийн цэгийг хүртээмжгүй хэвээр үлдээдэг.

Интерактив зам нь автоматжуулалтын муу загвар

Хүний нэвтрэлтийг скрипт болгох нь нэг удаа ажилладаг учраас уруу татагддаг. Скрипт нууц үг, магадгүй нэг удаагийн нууц үгийн үрийг хадгалж, дараа нь хүн шаардахаар зохиогдсон сорилтоос хамаардаг. OAuth-ын аюулгүй байдлын одоогийн шилдэг практик RFC 9700 нь resource-owner-password-credentials тэтгэлгийг хориглож, яагаад хоёр хүчин зүйлт болон олон шатлалт баталгаажуулалтад муу нийцдэгийг тайлбарладаг.

Дэмжигдсэн хувилбар нь ихэвчлэн нууц клиентийн урсгал бөгөөд зөвшөөрлийн сервер програмыг баталгаажуулж токен гаргадаг. RFC 6749-ийн 4.4 хэсгийн client-credentials тэтгэлэг нь нэг жишээ юм. Түүний оршин тогтнох нь API бүр түүнийг хүлээн авна гэсэн үг биш, хэрэглэгчийн төлөөлөн даалгасан ажлыг түүгээр сольж болно гэсэн үг ч биш, учир нь эдгээр нь үйлчилгээний эзэмшигчид тавих асуулт юм. Код бичихээс өмнө үйлчилгээ ямар хяналтгүй загварыг дэмждэгийг асууна уу.

VPN хаана хараахан тохирох вэ

VPN нь хувийн API-д шаардлагатай сүлжээний замыг өгч чадна, энэ нь хууль ёсны үүрэг юм. Энэ нь ажлыг програмд баталгаажуулдаггүй бөгөөд ажил юу хийж болохыг хязгаарладаггүй. Хамтарсан гарах хаяг нь ажлыг биш, хосттыг танина, тиймээс тухайн хаягийн зөвшөөрөгдсөн жагсаалтын бичлэг түүн дээр ажиллаж буй процес бүрийг нэвтрүүлдэг.

Хэрэв ажил хамтарсан гүйцэтгэгч дээр ажилладаг бол энэ ялгаа бага биш, илүү чухал. Нэг хост дээрх өөр ажлын урсгал зам, хаягийг өвлөн авдаг бөгөөд API хоёрыг ялгаж чадахгүй. Энэ нь хамтарсан нууц үгтэй ижил сул тал, нэг давхарга доош шилжсэн. Хязгаарлалтыг програм хэрэгжүүлж чадах газарт тавьж, зөвшөөрөгдсөн жагсаалтыг улам нарийсгаж чадахгүй бол гүйцэтгэгчийг тусгаарлана уу.

Хоёр загварыг шударгаар харьцуулна уу

Хүний нэвтрэлт танд жинхэнэ хүн, жинхэнэ хоёр дахь хүчин зүйл, аудит хийх боломжтой сессийг өгдөг бөгөөд хяналтгүй ажиллаж чадахгүй. Програмын таних тэмдэг нь хяналтгүй гүйцэтгэл, хянагдах хамрах хүрээ, эргүүлэх боломжтой итгэмжлэлийг өгдөг бөгөөд юу ч төлөөлөн даалгаагүй хэрэглэгчийн өмнөөс ажиллаж чадахгүй. Аль нь ч нөгөөгийнхөө сул хувилбар биш; тэд өөр асуултад хариулдаг. Ажил хэн ч байхгүйгээр ажиллах ёстой эсэх, үйлдлийг тодорхой хэрэглэгчид хамааруулах ёстой эсэхийг асууж сонгоно уу.

Хоёр хариулт ч тийм бол загварт зээлсэн нууц үг биш, төлөөлөн даалгах загвар хэрэгтэй. Тэр шийдвэрийг дараагийн засварчин олох газарт бичнэ үү.

Хүлээлгэн өгөхөөс өмнө юуг шалгах вэ

Бодит ажилтнаас нэг зөвшөөрөгдсөн үйлдэл, нэг заавал татгалзалтыг гүйцэтгэж, хоёр үр дүнг хадгална уу. Дараа нь хугацаа дууссан итгэмжлэл болон сүлжээний зам боломжгүй үеийн зан төлөвийг шалгана уу, учир нь шөнө хэн нэгнийг сэрээдэг нь тэр хоёр алдаа юм.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

Субъект, хамрах хүрээ, эргэлтийн эзэн, гүйцэтгэх орчныг тэр үр дүнгийн хажууд бүртгэнэ үү. Тэр бүртгэл нь дараагийн эргэлтийг осол биш, өдөр тутмын ажил болгодог. Аудитор шаарддаг хэсэг ч мөн адил.