Запланаваная задача ці ўваход чалавека: якую асобу павінна бачыць API?

Запланаваная задача і чалавек каля экрана ўваходу выклікаюць адзін і той жа API з рознымі ўліковымі данымі, рознымі тэрмінамі жыцця і рознымі ўладальнікамі. Задачы патрэбны сеткавы шлях, ідэнтычнасць праграмы і набор дазволаў; чалавеку патрэбны ўваход, другі фактар і сесія. Змешванне двух дае аўтаматызацыю, якая ламаецца кожны раз, калі змяняецца пароль чалавека, або шмафактарную палітыку, аслабленую роўна настолькі, каб задача cron заставалася жывой.

Тры брамы, якія выглядаюць як адна

Правіла адраса крыніцы пытаецца, адкуль прыйшоў запыт. Аўтэнтыфікацыя пытаецца, хто выклікае і якія доказы прад’яўлены. Аўтарызацыя пытаецца, ці можа гэты суб’ект выконваць гэтую аперацыю. VPN змяняе толькі першую з трох і змяняе яе для кожнага працэсу на хасту, а не толькі для задачы, таму тры назіранні трымайце асобна ў запісе інцыдэнту.

Менавіта таму змена вузла выхаду можа выправіць адмову па адрасе крыніцы і пакінуць нядзейны токен некранутым. І таму ж дзейны токен API не робіць прыватную канчатковую кропку дасяжнай з задачы, якая не мае да яе маршруту.

Інтэрактыўны шлях — дрэнны шаблон аўтаматызацыі

Пісаць скрыпт для ўваходу чалавека спакусліва, бо ён працуе адзін раз. Скрыпт захоўвае пароль, магчыма, зерне аднаразовага пароля, а затым залежыць ад выкліку, прызначанага патрабаваць чалавека. Найлепшая бягучая практыка бяспекі OAuth, RFC 9700, забараняе грант resource-owner-password-credentials і тлумачыць, чаму ён дрэнна падыходзіць для двухфактарнай і шмакрокавай аўтэнтыфікацыі.

Падтрыманая альтэрнатыва — звычайна паток канфідэнцыйнага кліента, у якім сервер аўтарызацыі аўтэнтыфікуе праграму і выдае токен. Грант client-credentials у RFC 6749, раздзел 4.4, — адзін прыклад. Яго наяўнасць не азначае, што кожны API яго прымае, ці што задачу, дэлегаваную карыстальнікам, можна ім замяніць, бо гэта пытанні да ўладальніка сэрвісу. Спытайце, якую мадэль без нагляду падтрымлівае сэрвіс, перш чым пісаць код.

Дзе VPN усё яшчэ да месца

VPN можа забяспечыць сеткавы шлях, які патрабуе прыватны API, і гэта законная роля. Ён не аўтэнтыфікуе задачу ў праграме і не вызначае межы таго, што задачы дазволена рабіць. Агульны адрас выхаду таксама ідэнтыфікуе хост, а не задачу, таму запіс у спісе дазволаў для гэтага адраса прапускае кожны працэс, які на ім выконваецца.

Калі задача выконваецца на агульным ранэры, гэтае адрозненне важнейшае, а не менш важнае. Іншая працоўная плынь на тым жа хасту наследуе маршрут і адрас, і API не можа іх адрозніць. Гэта тое ж слабое месца, што і агульны пароль, перанесенае на ўзровень ніжэй. Змясціце абмежаванне туды, дзе праграма можа яго забяспечыць, і ізалюйце ранэр, калі не можаце звузіць спіс дазволаў.

Параўнайце два праекты сумленна

Уваход чалавека дае вам рэальную асобу, рэальны другі фактар і сесію, якую можна аўдытаваць, але ён не можа працаваць без нагляду. Ідэнтычнасць праграмы дае вам выкананне без нагляду, аглядальныя межы і ўліковыя даныя, якія можна ратаваць, але яна не можа дзейнічаць за карыстальніка, які нічога не дэлегаваў. Ні адно не з’яўляецца слабейшай версіяй другога; яны адказваюць на розныя пытанні. Выбірайце, пытаючыся, ці павінна задача выконвацца без нікога, і ці павінна аперацыя прыпісвацца пэўнаму карыстальніку.

Калі абодва адказы — так, праекту патрэбна мадэль дэлегавання, а не пазычаны пароль. Запішыце гэтае рашэнне там, дзе яго знойдзе наступны суправаджальнік.

Што праверыць перад перадачай

Выканайце адну дазволеную аперацыю і адну абавязковую адмову ад фактычнага працоўнага і захавайце абодва вынікі. Затым праверце састарэлыя ўліковыя даныя і паводзіны, калі сеткавы шлях недаступны, бо гэта два збоі, якія будзяць кагосьці ноччу.

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

Запішыце суб’ект, межы, уладальніка ратацыі і асяроддзе выканання побач з гэтым вынікам. Менавіта гэты запіс робіць наступную ратацыю руціннай, а не інцыдэнтам. Гэта таксама частка, якую просіць аўдытар.