ਖਾਤਾ ਸੁਰੱਖਿਆ
ਸਰਵਰ ਸੁਰੱਖਿਆ ਸਾਈਟਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। ਖਾਤਾ ਸੁਰੱਖਿਆ ਉਹਨਾਂ ਦੀਆਂ ਕੁੰਜੀਆਂ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। ਹਰ Zinn Digital® ਲੌਗਇਨ ਇੱਕ ਮਿਆਰਾਂ-ਅਧਾਰਿਤ ਪਛਾਣ ਪ੍ਰਣਾਲੀ 'ਤੇ ਚੱਲਦਾ ਹੈ — ਪਾਸਕੀ ਅਤੇ WebAuthn, TOTP ਦੋ-ਪੱਖੀ ਪ੍ਰਮਾਣੀਕਰਨ, ਮੈਜਿਕ-ਲਿੰਕ ਸਾਈਨ-ਇਨ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਅਤੇ ਏਜੰਸੀ ਟੀਮਾਂ ਲਈ SAML SSO — ਜਿਸ ਦੇ ਪਿੱਛੇ ਵਿਸਤ੍ਰਿਤ ਭੂਮਿਕਾਵਾਂ, ਪ੍ਰਤੀ-ਸੰਸਥਾ API ਕੁੰਜੀਆਂ ਅਤੇ ਸਿਰਫ਼-ਜੋੜਨ ਵਾਲਾ ਆਡਿਟ ਲੌਗ ਮੌਜੂਦ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਹੋਸਟਿੰਗ ਖਾਤੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਪਾਸਵਰਡ ਹੁੰਦੇ ਹਨ, ਜੋ ਇੱਕ ਕੰਟਰੋਲ ਪੈਨਲ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਸਾਡਾ ਇੱਕ ਸਮਰਪਿਤ ਪਛਾਣ ਸਿਸਟਮ ਹੈ — Keycloak, ਜੋ OIDC ਅਤੇ SAML ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ — ਜੋ ਹਰ ਚੀਜ਼ ਦੇ ਸਾਹਮਣੇ ਕੰਮ ਕਰਦਾ ਹੈ: ਗਾਹਕ ਡੈਸ਼ਬੋਰਡ, ਸਟਾਫ ਐਡਮਿਨ ਕੰਸੋਲ, ਇਹ ਜਨਤਕ ਸਾਈਟ ਅਤੇ ਗਿਆਨ ਅਧਾਰ, ਅਤੇ ਤੁਹਾਡੀਆਂ ਸਹਾਇਤਾ ਟਿਕਟਾਂ। ਇੱਕ ਵਾਰ ਸਾਈਨ ਇਨ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਇਹਨਾਂ ਸਾਰਿਆਂ ਵਿੱਚ ਸਾਈਨ ਇਨ ਹੋ ਜਾਵੋਗੇ।
ਮਲਕੀਅਤੀ ਲੌਗਇਨ ਦੀ ਬਜਾਏ ਖੁੱਲ੍ਹੇ ਮਿਆਰਾਂ 'ਤੇ ਬਣਾਏ ਜਾਣ ਕਾਰਨ, ਪਛਾਣ ਪਰਤ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੇ ਹਰ ਦੂਜੇ ਹਿੱਸੇ ਵਾਂਗ ਹੀ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੇ ਪਹੁੰਚ ਮਾਡਲ ਦਾ ਕੋਈ ਵੀ ਹਿੱਸਾ ਕਿਸੇ ਵਿਕਰੇਤਾ ਦੇ ਉਤਪਾਦ ਦੇ ਅੰਦਰ ਫਸਿਆ ਨਹੀਂ ਰਹਿੰਦਾ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਦਾ ਪ੍ਰਮਾਣੀਕਰਨ ਸਾਡੇ ਇੱਕ ਸਪਲਾਇਰ ਨੂੰ ਬਣਾਈ ਰੱਖਣ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਇਹ ਉਹੀ ਨੋ-ਲਾਕ-ਇਨ ਸਿਧਾਂਤ ਹੈ ਜੋ ਅਸੀਂ CDN ਖਾਤਿਆਂ, DNS ਅਤੇ ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਾਂ।
ਸਾਈਨ-ਇਨ ਸਥਾਨਕੀਕਰਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਸਾਈਟ ਤੋਂ ਲੌਗਇਨ ਸਕ੍ਰੀਨ 'ਤੇ ਜਾਣ ਵੇਲੇ ਤੁਹਾਡੀ ਭਾਸ਼ਾ ਨਾਲ ਰਹਿੰਦੀ ਹੈ — ਤਾਂ ਜੋ ਵੱਖ-ਵੱਖ ਦੇਸ਼ਾਂ ਵਿੱਚ ਫੈਲੀ ਟੀਮ ਨੂੰ ਸਿਰਫ਼ ਅੰਗਰੇਜ਼ੀ ਲੌਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਨਾ ਹੋਣਾ ਪਵੇ।
ਚਾਰ ਤਰੀਕੇ, ਸਾਰੇ ਉੱਚ ਦਰਜੇ ਦੇ, ਸਾਰੇ ਪ੍ਰਤੀ ਵਿਅਕਤੀ ਸੰਰਚਨਾ ਯੋਗ। ਕਿਸੇ ਨੂੰ ਵੀ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਵਿਕਲਪ ਚੁਣਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਕਿਉਂਕਿ ਇਹ ਪੇਸ਼ਕਸ਼ 'ਤੇ ਮੌਜੂਦ ਇਕੋ-ਇਕ ਵਿਕਲਪ ਹੈ।
ਆਪਣੀ ਈਮੇਲ ਦਰਜ ਕਰੋ, ਲਿੰਕ 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਤੁਸੀਂ ਦਾਖਲ ਹੋ ਗਏ ਹੋ। ਫਿਸ਼ਿੰਗ ਕਰਨ, ਦੁਬਾਰਾ ਵਰਤਣ, ਜਾਂ ਡੇਟਾ ਉਲੰਘਣਾ ਵਿੱਚ ਲੀਕ ਹੋਣ ਲਈ ਕੋਈ ਪਾਸਵਰਡ ਨਹੀਂ ਹੈ। ਇਹ ਨਵੇਂ ਖਾਤਿਆਂ ਲਈ ਮੂਲ ਰਸਤਾ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਲੋਕਾਂ ਲਈ ਇਹ ਇੱਕੋ ਇੱਕ ਰਸਤਾ ਹੈ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਲੋੜ ਹੋਵੇਗੀ।
ਇੱਕ ਪਾਸਕੀ ਰਜਿਸਟਰ ਕਰੋ — Touch ID, Face ID, Windows Hello, ਜਾਂ YubiKey ਵਰਗੀ ਹਾਰਡਵੇਅਰ ਕੁੰਜੀ — ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਪਾਸਵਰਡ ਦੇ ਸਾਈਨ ਇਨ ਕਰੋ। ਪਾਸਕੀਆਂ ਮੂਲ ਨਾਲ ਬੱਝੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਕੋਈ ਮਿਲਦਾ-ਜੁਲਦਾ ਲੌਗਇਨ ਪੰਨਾ ਇਸਨੂੰ ਚੋਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਪਲੇਟਫਾਰਮ ES256 ਅਤੇ RS256 ਪ੍ਰਮਾਣਕਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਤਸਦੀਕ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਮਿਆਰੀ ਪਛਾਣ-ਪ੍ਰਦਾਤਾ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ Google ਨਾਲ ਸਾਈਨ ਇਨ ਕਰੋ, ਤਾਂ ਜੋ ਇੱਕ ਖਾਤਾ ਉਹਨਾਂ ਸਾਰੇ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰ ਲਵੇ ਜੋ ਤੁਹਾਡਾ Google Workspace ਪਹਿਲਾਂ ਹੀ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਹੋਰ ਪ੍ਰਦਾਤਾ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਜੁੜਦੇ ਹਨ — ਇਸ ਬਾਰੇ ਕੁਝ ਵੀ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਏਕੀਕਰਨ ਨਹੀਂ ਹੈ।
ਉਹਨਾਂ ਲੋਕਾਂ ਅਤੇ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਰੱਖਿਆ ਗਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇੱਕ ਅਸਲ ਨੀਤੀ ਅਧੀਨ ਰੱਖਿਆ ਗਿਆ ਹੈ: ਘੱਟੋ-ਘੱਟ ਬਾਰਾਂ ਅੱਖਰ, ਕਦੇ ਵੀ ਤੁਹਾਡਾ ਉਪਭੋਗਤਾ ਨਾਮ ਜਾਂ ਈਮੇਲ ਪਤਾ ਨਹੀਂ, ਤੁਹਾਡੇ ਪਿਛਲੇ ਤਿੰਨਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਨਹੀਂ, Argon2 ਨਾਲ ਹੈਸ਼ ਕੀਤਾ ਗਿਆ। ਖਾਤਾ ਵਰਤੋਂ ਯੋਗ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਈਮੇਲ ਪਤਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਦੂਜੇ ਕਾਰਕ ਪਛਾਣ ਪ੍ਰਣਾਲੀ ਦਾ ਹਿੱਸਾ ਹਨ, ਕੋਈ ਅਜਿਹਾ ਐਡ-ਆਨ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਖਰੀਦਦੇ ਹੋ ਜਾਂ ਕੋਈ ਪਲੱਗਇਨ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਸਾਈਟ 'ਤੇ ਸਥਾਪਤ ਕਰਦੇ ਹੋ।
ਜੇਕਰ ਤੁਹਾਡੀ ਸੰਸਥਾ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਪਛਾਣ ਪ੍ਰਦਾਤਾ (identity provider) ਚਲਾ ਰਹੀ ਹੈ — Okta, Entra ID, Google Workspace, ਜਾਂ SAML ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੀ ਕੋਈ ਹੋਰ ਚੀਜ਼ — ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕਨੈਕਟ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਲੋਕ ਆਪਣੇ ਮੌਜੂਦਾ ਕਾਰਪੋਰੇਟ ਵੇਰਵਿਆਂ ਨਾਲ Zinn Digital® ਵਿੱਚ ਸਾਈਨ ਇਨ ਕਰਦੇ ਹਨ। ਤੁਹਾਡੀ ਟੀਮ ਲਈ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਕੋਈ ਦੂਜਾ ਪਾਸਵਰਡ ਨਹੀਂ ਹੈ, ਅਤੇ ਭੁੱਲਣ ਲਈ ਕੋਈ ਦੂਜੀ ਆਫ਼ਬੋਰਡਿੰਗ ਚੈੱਕਲਿਸਟ ਨਹੀਂ ਹੈ।
ਇਹ ਏਜੰਸੀ ਅਤੇ ਰੀਸੈਲਰ ਪੱਧਰ 'ਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਸਟਾਫ਼ ਦਾ ਛੱਡ ਕੇ ਜਾਣਾ ਇੱਕ ਅਸਲ ਸੁਰੱਖਿਆ ਮਾਮਲਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਛੱਡਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਆਪਣੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਅਸਮਰੱਥ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੀ ਹੋਸਟਿੰਗ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਦਾਖਲੇ ਦਾ ਰਸਤਾ ਵੀ ਅਸਮਰੱਥ ਕਰ ਦਿੱਤਾ ਹੁੰਦਾ ਹੈ। ਦਰਜਨਾਂ SaaS ਟੂਲਸ ਵਿੱਚ ਪਿੱਛਾ ਕਰਨ ਦੀ ਬਜਾਏ, ਪਹੁੰਚ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਰੁਜ਼ਗਾਰ ਦੇ ਅਨੁਸਾਰ ਚੱਲਦੀ ਹੈ।
SAML ਬਾਕੀ ਸਭ ਕੁਝ ਬਦਲਣ ਦੀ ਬਜਾਏ ਉਸਦੇ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ: ਠੇਕੇਦਾਰਾਂ ਨੂੰ ਅਜੇ ਵੀ ਇੱਕ ਦਾਇਰੇ ਵਾਲੀ ਭੂਮਿਕਾ ਦੇ ਅੰਦਰ ਇੱਕ ਮੈਜਿਕ-ਲਿੰਕ ਖਾਤਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਥਾਈ ਸਟਾਫ SSO ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ। ਇੱਕ ਸੰਸਥਾ, ਇੱਕ ਅਨੁਮਤੀ ਮਾਡਲ, ਦੋ ਮੁੱਖ ਦਰਵਾਜ਼ੇ।
ਪਹੁੰਚ ਨੂੰ ਸੰਸਥਾ ਦੇ ਢਾਂਚੇ ਮੁਤਾਬਕ ਸੀਮਤ ਕੀਤਾ ਗਿਆ ਹੈ — ਰੀਸੈਲਰ ਤੋਂ ਕਲਾਇੰਟ ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ ਸਾਈਟ ਤੱਕ — ਅਤੇ ਇਸਨੂੰ ਸਿਰਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਕਤਾਰ-ਪੱਧਰੀ ਸੁਰੱਖਿਆ ਰਾਹੀਂ ਡਾਟਾਬੇਸ ਵਿੱਚ ਖੁਦ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕ੍ਰਾਸ-ਕਿਰਾਏਦਾਰ ਪਹੁੰਚ ਕੋਈ ਅਜਿਹੀ ਨੀਤੀ ਨਹੀਂ ਹੈ ਜਿਸਦੀ ਅਸੀਂ ਲੋਕਾਂ ਨੂੰ ਪਾਲਣਾ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹਾਂ; ਇਹ ਇੱਕ ਅਜਿਹੀ ਪੁੱਛਗਿੱਛ (ਕਵੇਰੀ) ਹੈ ਜੋ ਕਤਾਰਾਂ ਵਾਪਸ ਕਰ ਹੀ ਨਹੀਂ ਸਕਦੀ। ਚਾਰ ਗਾਹਕ ਭੂਮਿਕਾਵਾਂ ਕਰਤੱਵਾਂ ਦੀ ਅਸਲ ਵੰਡ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ।
ਸੰਸਥਾ ਅਤੇ ਇਸਦੇ ਉਪ-ਖਾਤਿਆਂ 'ਤੇ ਪੂਰਾ ਕੰਟਰੋਲ: ਉਪ-ਸੰਸਥਾਵਾਂ ਬਣਾਓ, ਮੈਂਬਰਾਂ ਨੂੰ ਸੱਦਾ ਦਿਓ ਅਤੇ ਹਟਾਓ, ਭੂਮਿਕਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ, ਹਰੇਕ ਸਾਈਟ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ, ਬਿਲਿੰਗ ਅਤੇ ਇਨਵੌਇਸਿੰਗ ਚਲਾਓ, API ਕੁੰਜੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ, ਅਤੇ ਆਡਿਟ ਲੌਗ ਪੜ੍ਹੋ।
ਇਨਵੌਇਸ, ਗਾਹਕੀਆਂ, ਭੁਗਤਾਨ ਵਿਧੀਆਂ ਅਤੇ ਯੋਜਨਾ ਕੈਟਾਲਾਗ — ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਤੁਹਾਡਾ ਵਿੱਤ ਵਿਅਕਤੀ ਜਾਂ ਲੇਖਾਕਾਰ ਲਾਈਵ ਸਾਈਟ ਨੂੰ ਛੂਹਣ, ਮੁਅੱਤਲ ਕਰਨ ਜਾਂ ਮਿਟਾਉਣ ਦੀ ਸਮਰੱਥਾ ਰੱਖੇ ਬਿਨਾਂ ਵੀ ਇਨਵੌਇਸ ਦਾ ਨਿਪਟਾਰਾ ਕਰ ਸਕਦਾ ਹੈ।
ਬਿਲਿੰਗ ਨਿਯੰਤਰਣ ਤੋਂ ਬਿਨਾਂ ਸਾਈਟਾਂ ਅਤੇ API ਪਹੁੰਚ: ਸਾਈਟਾਂ ਦੇਖੋ ਅਤੇ ਵਿਵਸਥਿਤ ਕਰੋ, ਸੇਵਾਵਾਂ ਮੁੜ-ਚਾਲੂ ਕਰੋ, ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ, API ਕੁੰਜੀਆਂ ਅਤੇ ਕੰਮ ਦੀਆਂ ਟਿਕਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ। ਜਾਣਬੁੱਝ ਕੇ ਭੁਗਤਾਨ ਵਿਧੀਆਂ, ਇਨਵੌਇਸਿੰਗ ਜਾਂ ਯੋਜਨਾ ਤਬਦੀਲੀਆਂ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਹੈ।
ਸੰਸਥਾ ਭਰ ਵਿੱਚ ਸਿਰਫ਼ ਦੇਖਣ ਲਈ — ਸਾਈਟਾਂ, ਬਿਲਿੰਗ, ਪਲਾਨ, ਟਿਕਟਾਂ, ਅਨੁਵਾਦ ਸਥਿਤੀ ਅਤੇ ਆਡਿਟ ਲੌਗ। ਇੱਕ ਆਡੀਟਰ, ਦਿੱਖ ਚਾਹੁਣ ਵਾਲੇ ਗਾਹਕ, ਜਾਂ ਆਪਣੇ ਪਹਿਲੇ ਹਫ਼ਤੇ ਵਿੱਚ ਨਵੇਂ ਸ਼ਾਮਲ ਹੋਏ ਕਰਮਚਾਰੀ ਲਈ ਸਹੀ ਭੂਮਿਕਾ।
ਡੈਸ਼ਬੋਰਡ ਪਹੁੰਚ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ। API, CLI, Terraform ਪ੍ਰਦਾਤਾ ਅਤੇ MCP ਸਰਵਰ ਹੋਰ ਤਰੀਕੇ ਹਨ — ਅਤੇ ਉਹ ਉਸੇ ਪਹੁੰਚ ਮਾਡਲ ਦੇ ਅਧੀਨ ਆਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਇੱਕ ਅਣ-ਨਿਰਧਾਰਤ ਦਾਇਰੇ ਵਾਲੀ ਕੁੰਜੀ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਕੌਂਫਿਗਰ ਕੀਤੀ ਹਰੇਕ ਭੂਮਿਕਾ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਦਿੰਦੀ ਹੈ।
ਇੱਕ API ਕੁੰਜੀ ਕਿਸੇ ਵਿਅਕਤੀ ਵਿਸ਼ੇਸ਼ ਨੂੰ ਨਹੀਂ, ਸਗੋਂ ਕਿਸੇ ਸੰਸਥਾ ਨੂੰ ਜਾਰੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਸਦੇ ਆਪਣੇ ਘੇਰੇ (ਸਕੋਪ) ਹੁੰਦੇ ਹਨ। ਇਸਨੂੰ ਸਾਂਝੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਜੋਂ ਵਰਤੋ: ਇਸਦੇ ਉਦੇਸ਼ ਅਨੁਸਾਰ ਇਸਦਾ ਨਾਮ ਰੱਖੋ, ਕੰਮ ਲਈ ਲੋੜੀਂਦੇ ਸਭ ਤੋਂ ਸੀਮਤ ਘੇਰੇ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਜਦੋਂ ਇਸਨੂੰ ਬਣਾਉਣ ਵਾਲਾ ਵਿਅਕਤੀ ਅੱਗੇ ਚਲਾ ਜਾਵੇ ਤਾਂ ਇਸਨੂੰ ਬਦਲ ਦਿਓ।
ਅਣਸੋਧੀ ਕੁੰਜੀ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ, ਬਣਾਉਣ ਸਮੇਂ ਹੀ ਦਿਖਾਈ ਜਾਂਦੀ ਹੈ। ਅਸੀਂ ਸਿਰਫ਼ ਇੱਕ SHA-256 ਹੈਸ਼ ਅਤੇ ਖੋਜ ਲਈ ਇੱਕ ਛੋਟਾ ਅਗੇਤਰ ਰੱਖਦੇ ਹਾਂ। ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਕੁੰਜੀ ਨਹੀਂ ਦਿਖਾ ਸਕਦੇ, ਅਤੇ ਡਾਟਾਬੇਸ ਨਾਲ ਸਮਝੌਤਾ ਹੋਣ 'ਤੇ ਵੀ ਹਮਲਾਵਰ ਦੇ ਹੱਥ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਹੀਂ ਲੱਗਦੇ।
ਹਰੇਕ ਕੁੰਜੀ ਵਿੱਚ ਭੂਮਿਕਾਵਾਂ ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਉਸੇ ਇਜਾਜ਼ਤ ਸੂਚੀ ਨਾਲ ਜੁੜੇ ਵਿਸਤ੍ਰਿਤ ਦਾਇਰੇ ਹੁੰਦੇ ਹਨ, ਇਹ ਰਿਕਾਰਡ ਕਰਦੀ ਹੈ ਕਿ ਇਸਨੂੰ ਆਖਰੀ ਵਾਰ ਕਦੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਜਿਵੇਂ ਹੀ ਇਹ ਸ਼ੱਕੀ ਜਾਪਦੀ ਹੈ, ਇਸਨੂੰ ਤੁਰੰਤ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵੱਖਰੀਆਂ ਸੈਂਡਬੌਕਸ ਕੁੰਜੀਆਂ ਆਪਣੇ ਪਿੱਛੇ ਬਿਨਾਂ ਕਿਸੇ ਅਸਲ ਬਿਲਿੰਗ ਜਾਂ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਦੇ API ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।
MCP ਸਰਵਰ ਕਿਸੇ ਵੀ MCP-ਸਮਰੱਥ ਏਜੰਟ ਨੂੰ ਤੁਹਾਡੀ ਹੋਸਟਿੰਗ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ — ਅਤੇ ਇਹ OAuth 2.1 ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੀ ਸੰਸਥਾ ਅਤੇ ਇਸਦੀਆਂ RBAC ਇਜਾਜ਼ਤਾਂ ਤੱਕ ਸੀਮਿਤ ਹੈ, ਪ੍ਰਤੀ-ਟੂਲ ਰੱਦ ਕੀਤੇ ਜਾਣ ਯੋਗ ਟੋਕਨਾਂ, ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ 'ਤੇ ਪੁਸ਼ਟੀਕਰਨ, ਖਰਚ ਸੀਮਾਵਾਂ ਅਤੇ ਪੂਰੀ ਆਡਿਟ ਲੌਗਿੰਗ ਦੇ ਨਾਲ। ਇੱਕ AI ਸਹਾਇਕ ਨੂੰ ਕਨੈਕਟ ਕਰਨ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਇਸਨੂੰ ਹਰ ਚੀਜ਼ ਦੀਆਂ ਕੁੰਜੀਆਂ ਸੌਂਪ ਦਿੱਤੀਆਂ ਜਾਣ।
ਹਰੇਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਾਰਵਾਈ ਇੱਕ ਸਿਰਫ਼-ਜੋੜਨ-ਯੋਗ ਰਿਕਾਰਡ ਲਿਖਦੀ ਹੈ — ਕਿਸਨੇ ਇਹ ਕੀਤਾ, ਉਹਨਾਂ ਨੇ ਕੀ ਕੀਤਾ, ਉਹਨਾਂ ਨੇ ਕਿਸ 'ਤੇ ਇਹ ਕੀਤਾ, ਸਮਰਥਕ ਸਬੂਤ, ਅਤੇ ਸਰੋਤ IP ਪਤਾ, ਇੱਕ ਸਮਾਂ-ਮੋਹਰ ਸਮੇਤ। ਇਹ ਡੀਬੱਗਿੰਗ ਦੀ ਸਹੂਲਤ ਨਹੀਂ ਹੈ; ਇਹ ਸਬੂਤਾਂ ਦਾ ਸਿਲਸਿਲਾ ਹੈ।
ਨਹੀਂ — ਅਤੇ ਅਸੀਂ ਚਾਹਾਂਗੇ ਕਿ ਤੁਸੀਂ ਅਜਿਹਾ ਨਾ ਕਰੋ। ਮੈਜਿਕ-ਲਿੰਕ ਈਮੇਲ ਸਾਈਨ-ਇਨ ਡਿਫੌਲਟ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਪਾਸਕੀ (Touch ID, Face ID, Windows Hello ਜਾਂ ਇੱਕ ਹਾਰਡਵੇਅਰ ਕੁੰਜੀ) ਰਜਿਸਟਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਬਿਨਾਂ ਕੋਈ ਪਾਸਵਰਡ ਸੈੱਟ ਕੀਤੇ ਸਾਈਨ ਇਨ ਕਰ ਸਕਦੇ ਹੋ। ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ ਇੱਕ ਬੈਕਅੱਪ ਵਜੋਂ ਉਪਲਬਧ ਰਹਿੰਦੇ ਹਨ, ਜਿਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਬਾਰਾਂ ਅੱਖਰਾਂ ਦੀ ਸੀਮਾ, ਤੁਹਾਡੇ ਪਿਛਲੇ ਤਿੰਨ ਪਾਸਵਰਡਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਨਾ ਹੋਣਾ, ਅਤੇ Argon2 ਹੈਸ਼ਿੰਗ ਲਾਜ਼ਮੀ ਹੈ।
TOTP ਦੋ-ਪੜਾਵੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪਛਾਣ ਪਰਤ ਵਿੱਚ ਹੀ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਹਰੇਕ ਮੈਂਬਰ ਦੀ ਮਰਜ਼ੀ 'ਤੇ ਛੱਡਣ ਦੀ ਬਜਾਏ ਕਿਸੇ ਸੰਸਥਾ ਵਿੱਚ ਨੀਤੀ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜਿੱਥੇ ਤੁਹਾਡੀ ਟੀਮ ਦੇ ਡਿਵਾਈਸ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਉੱਥੇ ਪਾਸਕੀਜ਼ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਵਿਕਲਪ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਉਸ ਪਾਸਵਰਡ ਨੂੰ ਹੀ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਕੋਈ ਹਮਲਾਵਰ ਫਿਸ਼ਿੰਗ ਰਾਹੀਂ ਚੋਰੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ।
ਹਾਂ। ਬਿਲਿੰਗ ਮੈਨੇਜਰ (Billing Manager) ਭੂਮਿਕਾ ਇਨਵੌਇਸ, ਗਾਹਕੀਆਂ, ਭੁਗਤਾਨ ਵਿਧੀਆਂ ਅਤੇ ਯੋਜਨਾ ਕੈਟਾਲਾਗ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ — ਕਿਸੇ ਸਾਈਟ ਨੂੰ ਵੇਖਣ, ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨ, ਮੁੜ ਚਾਲੂ ਕਰਨ, ਮੁਅੱਤਲ ਕਰਨ ਜਾਂ ਮਿਟਾਉਣ ਦੀ ਕੋਈ ਸਮਰੱਥਾ ਨਹੀਂ। ਇਸਦੇ ਉਲਟ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਡਿਵੈਲਪਰ (Developer) ਭੂਮਿਕਾ ਬਿਨਾਂ ਕਿਸੇ ਬਿਲਿੰਗ ਨਿਯੰਤਰਣ ਦੇ ਸਾਈਟਾਂ ਅਤੇ API ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੀ ਹੈ। ਭੂਮਿਕਾਵਾਂ ਪ੍ਰਤੀ ਸੰਸਥਾ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਸੰਸਥਾ ਵਿੱਚ ਇੱਕ ਭੂਮਿਕਾ ਇੱਕ ਵੱਖਰੀ, ਗੈਰ-ਸੰਬੰਧਿਤ ਸੰਸਥਾ ਵਿੱਚ ਕੋਈ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ — ਹਾਲਾਂਕਿ ਇੱਕ ਮੂਲ ਸੰਸਥਾ ਵਿੱਚ ਇੱਕ ਭੂਮਿਕਾ ਇਸਦੇ ਅਧੀਨ ਆਉਣ ਵਾਲੀਆਂ ਸੰਸਥਾਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਇਸਨੂੰ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਰੱਦ ਕਰੋ ਅਤੇ ਇਹ ਤੁਰੰਤ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਨੁਕਸਾਨ ਦਾ ਦਾਇਰਾ ਇਸ ਗੱਲ ਤੱਕ ਸੀਮਿਤ ਹੈ ਕਿ ਉਹ ਕੁੰਜੀ ਸ਼ੁਰੂ ਵਿੱਚ ਕੀ ਕਰ ਸਕਦੀ ਸੀ, ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਕੁੰਜੀਆਂ ਵਿੱਚ ਬਾਰੀਕ ਸਕੋਪ ਹੁੰਦੇ ਹਨ ਅਤੇ ਆਖਰੀ ਵਾਰ ਵਰਤੋਂ ਕੀਤੇ ਜਾਣ ਦਾ ਸਮਾਂ ਰਿਕਾਰਡ ਹੁੰਦਾ ਹੈ — ਸੀਮਤ ਸਕੋਪ ਅਤੇ ਇੱਕ ਦਿੱਖਣ ਵਾਲਾ ਵਰਤੋਂ ਟ੍ਰੇਲ ਹੀ ਲੀਕ ਨੂੰ ਇੱਕ ਪੂਰੇ ਖਾਤੇ ਦੇ ਸਮਝੌਤੇ ਦੀ ਬਜਾਏ ਇੱਕ ਨਿਯੰਤਰਿਤ ਘਟਨਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਕੁੰਜੀਆਂ ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਬਜਾਏ ਸੰਸਥਾ ਨੂੰ ਜਾਰੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ ਸਾਂਝੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਵਜੋਂ ਵਰਤੋ ਅਤੇ ਜਦੋਂ ਲੋਕ ਬਦਲਦੇ ਹਨ ਤਾਂ ਇਹਨਾਂ ਨੂੰ ਰੋਟੇਟ ਕਰੋ। ਸਾਡੇ ਪਾਸੇ ਸਿਰਫ਼ ਕੁੰਜੀ ਦਾ ਹੈਸ਼ ਹੀ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਾਡੇ ਡੇਟਾਬੇਸ ਤੋਂ ਲੀਕ ਹੋਣ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਹੀਂ ਬਣਦਾ।
ਹਾਂ। ਹਰੇਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਾਰਵਾਈ ਨੂੰ ਕਰਤਾ, ਕਾਰਵਾਈ, ਨਿਸ਼ਾਨਾ, ਸਹਾਇਕ ਸਬੂਤ, ਸਰੋਤ IP ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਦੇ ਨਾਲ ਸਿਰਫ਼-ਜੋੜਨ ਵਾਲੇ ਆਡਿਟ ਲੌਗ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮਾਲਕ ਅਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀਆਂ ਭੂਮਿਕਾਵਾਂ ਇਸਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਦੇਖ ਸਕਦੀਆਂ ਹਨ। ਤੁਹਾਡੇ ਖਾਤੇ 'ਤੇ ਸਟਾਫ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਉਸੇ ਟ੍ਰੇਲ ਵਿੱਚ ਲੌਗ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਂ ਵਿਨਾਸ਼ਕਾਰੀ ਸਟਾਫ ਕਾਰਵਾਈਆਂ ਲਈ ਪਹਿਲਾਂ ਵਾਧੂ ਪ੍ਰਮਾਣੀਕਰਨ ਜਾਂ ਦੋ-ਵਿਅਕਤੀਆਂ ਦੀ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਹਾਂ — ਐਂਟਰਪ੍ਰਾਈਜ਼ ਅਤੇ ਏਜੰਸੀ ਖਾਤਿਆਂ ਲਈ SAML SSO ਸਮਰਥਿਤ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡੇ ਲੋਕ ਮੌਜੂਦਾ ਕਾਰਪੋਰੇਟ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਆਫਬੋਰਡਿੰਗ ਕਰਨ ਨਾਲ ਇੱਥੇ ਵੀ ਉਹਨਾਂ ਦੀ ਪਹੁੰਚ ਹਟ ਜਾਂਦੀ ਹੈ। ਤੁਸੀਂ ਪਹੁੰਚਾਂ ਨੂੰ ਮਿਲਾ ਸਕਦੇ ਹੋ: ਸਥਾਈ ਸਟਾਫ ਲਈ SSO, ਠੇਕੇਦਾਰਾਂ ਲਈ ਸਕੋਪਡ ਮੈਜਿਕ-ਲਿੰਕ ਖਾਤੇ, ਸਾਰੇ ਇੱਕੋ ਇਜਾਜ਼ਤ ਮਾਡਲ ਦੇ ਅੰਦਰ।
ਨਹੀਂ — ਪਾਸਵਰਡ ਜਾਣਬੁੱਝ ਕੇ ਮਾਈਗ੍ਰੇਟ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ। ਤੁਹਾਡਾ ਖਾਤਾ ਬਿਨਾਂ ਪਾਸਵਰਡ ਦੇ ਆਯਾਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਵਾਰ ਸਾਈਨ-ਇਨ ਕਰਨ 'ਤੇ ਤੁਸੀਂ ਜਾਂ ਤਾਂ magic-link ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਜਾਂ ਮੌਜੂਦਾ ਨੀਤੀ ਦੇ ਤਹਿਤ ਇੱਕ ਨਵਾਂ ਪਾਸਵਰਡ ਸੈੱਟ ਕਰਦੇ ਹੋ। ਪੁਰਾਣੇ ਪਾਸਵਰਡ ਹੈਸ਼ਾਂ ਨੂੰ ਪੋਰਟ ਕਰਨਾ ਨਵੇਂ ਸਿਸਟਮ ਵਿੱਚ ਪੁਰਾਣੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਲਿਆਏਗਾ, ਇਸ ਲਈ ਅਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ।
Footprint-Free ਟ੍ਰਾਇਲ 14 ਦਿਨਾਂ ਦਾ ਹੈ, ਕਾਰਡ-ਮੁਕਤ ਹੈ, ਅਤੇ ਪੰਜ ਸਾਈਟਾਂ ਤੱਕ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਟ੍ਰਾਇਲ ਦੌਰਾਨ ਤੁਹਾਨੂੰ ਪੂਰੀ ਪਛਾਣ ਪਰਤ ਮਿਲਦੀ ਹੈ — ਪਾਸਕੁੰਜੀਆਂ, ਦੋ-ਪੜਾਵੀ ਪ੍ਰਮਾਣਿਕਤਾ, ਭੂਮਿਕਾਵਾਂ, API ਕੁੰਜੀਆਂ ਅਤੇ ਆਡਿਟ ਲੌਗ ਕਿਸੇ ਭੁਗਤਾਨ ਕੀਤੇ ਪਲਾਨ ਪਿੱਛੇ ਸੀਮਤ ਨਹੀਂ ਹਨ।
ਇੱਕ ਪਾਸ-ਕੀ ਦਰਜ ਕਰੋ, ਆਪਣੀ ਟੀਮ ਨੂੰ ਸਹੀ ਭੂਮਿਕਾਵਾਂ ਵਿੱਚ ਸੱਦਾ ਦਿਓ, ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਦਾਇਰੇ ਵਾਲੀ API ਕੁੰਜੀ ਜਾਰੀ ਕਰੋ — ਇਹ ਸਭ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਡ ਦੇ ਵੇਰਵਿਆਂ ਦੀ ਲੋੜ ਵਾਲੇ 14-ਦਿਨਾਂ ਦੇ ਟ੍ਰਾਇਲ 'ਤੇ ਉਪਲਬਧ ਹੈ।
ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ