ਯੂਨਿਟ 4 / 11

ਪਹੁੰਚ ਨਿਯੰਤਰਣ, ਪਛਾਣ ਅਤੇ ਗੁਪਤ ਪ੍ਰਬੰਧਨ

ਲਾਭ:

  • ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਨੂੰ ਵੱਖ ਕਰਨ ਅਤੇ RBAC/ABAC ਨਾਲ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਲਾਗੂ ਕਰਨ ਦੀ ਸਮਰੱਥਾ
  • ਉਪਭੋਗਤਾ ਸੰਦਰਭ ਵਿੱਚ ਮਾਡਲ ਨੂੰ ਚਲਾ ਕੇ ਮਿਸ਼ਰਤ ਪ੍ਰੌਕਸੀ ਜੋਖਮ ਤੋਂ ਬਚਣ ਦੀ ਸਮਰੱਥਾ
  • ਗੁਪਤ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਨਾਲ API ਕੁੰਜੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਘੁੰਮਾਉਣ ਦੀ ਸਮਰੱਥਾ

ਇੱਕ AI ਸਿਸਟਮ 'ਤੇ ਹਮਲਿਆਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਮਾਡਲ ਨੂੰ "ਚਲਾਉਣ" ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਚੋਰੀ ਕੀਤੀ API ਕੁੰਜੀ ਜਾਂ ਇੱਕ ਓਵਰ-ਅਧਿਕਾਰਤ ਖਾਤੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਦੀ ਇਹ ਪਰਤ ਕਲਾਸੀਕਲ ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਆ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਪਰ AI ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਨਵੇਂ ਜੋਖਮਾਂ ਨੂੰ ਜੋੜਦੀ ਹੈ: ਇੱਕ ਮਾਡਲ ਕਿਸੇ ਹੋਰ ਦੀ ਤਰਫ਼ੋਂ ਇੱਕ ਰਾਈਡ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਇੱਕ ਸੇਵਾ ਖਾਤਾ ਸਾਰੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ, GitHub ਨੂੰ ਇੱਕ ਕੁੰਜੀ ਲੀਕ ਕਰਦਾ ਹੈ। ਇਸ ਯੂਨਿਟ ਵਿੱਚ, ਅਸੀਂ ਸਿਖਾਂਗੇ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ, ਅਧਿਕਾਰ (RBAC/ABAC), ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਅਤੇ ਗੁਪਤ ਪ੍ਰਬੰਧਨ ਨਾਲ AI ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਕਿਵੇਂ ਸੀਮਤ ਕਰਨਾ ਹੈ।

ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਚਕਾਰ ਅੰਤਰ

ਦੋ ਸ਼ਬਦ ਅਕਸਰ ਉਲਝਣ ਵਿੱਚ ਹੁੰਦੇ ਹਨ:

  • ਪ੍ਰਮਾਣਿਕਤਾ: "ਤੁਸੀਂ ਕੌਣ ਹੋ?" — ਇਹ ਸਾਬਤ ਕਰਨਾ ਕਿ ਉਪਭੋਗਤਾ/ਸੇਵਾ ਅਸਲ ਵਿੱਚ ਉਹ ਹੈ ਜੋ ਉਹ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ (ਪਾਸਵਰਡ, ਟੋਕਨ, ਸਰਟੀਫਿਕੇਟ, MFA)।
  • ਅਧਿਕਾਰ: "ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ?" — ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਪ੍ਰਮਾਣਿਤ ਪਾਰਟੀ ਕਿਸ ਸਰੋਤ/ਕਿਰਿਆ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੀ ਹੈ।

ਏਆਈ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਣ ਸੂਖਮਤਾ ਇਹ ਹੈ: ਜਦੋਂ ਮਾਡਲ ਇੱਕ ਉਪਭੋਗਤਾ ਦੀ ਤਰਫੋਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਕੀ ਇਹ ਉਸ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਇੱਕ ਵਿਆਪਕ ਸੇਵਾ ਖਾਤੇ ਨਾਲ? ਬਾਅਦ ਵਾਲਾ ਖ਼ਤਰਨਾਕ ਹੈ - ਕਿਉਂਕਿ ਇੰਜੈਕਸ਼ਨ ਦੁਆਰਾ ਚਲਾਏ ਗਏ ਮਾਡਲ ਨੂੰ ਸੇਵਾ ਖਾਤੇ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ।

ਸਾਵਧਾਨ: "ਉਲਝਣ ਵਾਲਾ ਡਿਪਟੀ" ਸਮੱਸਿਆ: ਇੱਕ ਘੱਟ-ਅਥਾਰਟੀ ਉਪਭੋਗਤਾ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ ਜਿਸ ਤੱਕ ਉਹ ਉੱਚ-ਅਥਾਰਟੀ ਮਾਡਲ ਆਊਟਸੋਰਸਿੰਗ ਦੁਆਰਾ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਮਾਡਲ ਨੂੰ ਹਮੇਸ਼ਾਂ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਉਸਦੇ ਆਪਣੇ ਵਿਆਪਕ ਅਧਿਕਾਰ ਦੇ।

RBAC ਅਤੇ ABAC

  • RBAC (ਰੋਲ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ): ਪਹੁੰਚ ਉਪਭੋਗਤਾ ਦੀ ਭੂਮਿਕਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। "ਸਹਾਇਤਾ ਮਾਹਰ" ਦੀ ਭੂਮਿਕਾ ਗਾਹਕ ਨੋਟ ਪੜ੍ਹ ਸਕਦੀ ਹੈ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਮਿਟਾ ਨਹੀਂ ਸਕਦੀ। ਸਧਾਰਨ ਅਤੇ ਆਮ.
  • ABAC (ਵਿਸ਼ੇਸ਼ਤਾ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ): ਪਹੁੰਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ: ਉਪਭੋਗਤਾ ਦਾ ਵਿਭਾਗ, ਡੇਟਾ ਦਾ ਗੋਪਨੀਯਤਾ ਲੇਬਲ, ਦਿਨ ਦਾ ਸਮਾਂ, ਉਹ ਨੈਟਵਰਕ ਜਿਸ ਤੋਂ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ। ਵਧੇਰੇ ਵਧੀਆ ਪਰ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ।

ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ RBAC ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਲਈ ABAC ਤੱਕ ਡੂੰਘੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। AI ਲਈ ਅੰਗੂਠੇ ਦਾ ਨਿਯਮ: ਮਾਡਲ ਨੂੰ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਦੀ ਭੂਮਿਕਾ/ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਹਰ ਏਜੰਟ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ਉਹ ਕਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਹਰੇਕ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ।

ਕਦਮ ਦਰ ਕਦਮ: ਘੱਟੋ-ਘੱਟ ਅਥਾਰਟੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

  1. ਵਸਤੂ ਸੂਚੀ ਲਵੋ. ਮਾਡਲ ਕਿਹੜੇ ਟੂਲਸ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਇਹ ਕਿਹੜੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ? ਉਹਨਾਂ ਸਾਰਿਆਂ ਦੀ ਸੂਚੀ ਬਣਾਓ।
  2. ਹਰੇਕ ਪਹੁੰਚ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਓ। "ਕੀ ਇਸ ਸਹਾਇਕ ਨੂੰ ਅਸਲ ਵਿੱਚ ਮਿਟਾਉਣ ਦੇ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਹੈ?" ਨਹੀਂ ਤਾਂ, ਇਸਨੂੰ ਹਟਾਓ.
  3. ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਪੂਰਵ-ਨਿਰਧਾਰਤ। ਮਾਡਲ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਪੜ੍ਹਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਵੱਖਰੇ, ਤੰਗ-ਸਕੋਪ ਟੋਕਨ ਨੂੰ ਲਿਖਣ/ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਹੈ।
  4. ਉਪਭੋਗਤਾ ਸੰਦਰਭ ਨੂੰ ਮੂਵ ਕਰੋ। ਵਾਹਨ ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰ ਨਾਲ ਕਾਲ ਕਰੋ, ਸੇਵਾ ਖਾਤੇ ਨਾਲ ਨਹੀਂ।
  5. ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਪ੍ਰਮਾਣ ਪੱਤਰ। ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਕੁੰਜੀਆਂ ਦੀ ਬਜਾਏ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ, ਸਵੈ-ਨਵੀਨੀਕਰਨ ਵਾਲੇ ਟੋਕਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਗੁਪਤ ਪ੍ਰਬੰਧਨ

ਇੱਕ ਗੁਪਤ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਹੁੰਦਾ ਹੈ ਜੋ ਗੁਪਤ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ API ਕੁੰਜੀ, ਪਾਸਵਰਡ, ਟੋਕਨ, ਜਾਂ ਸਰਟੀਫਿਕੇਟ। AI ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਦੁਰਘਟਨਾ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਮਾਡਲ ਪ੍ਰਦਾਤਾ ਦੀ API ਕੁੰਜੀ ਕੋਡ ਵਿੱਚ ਏਮਬੇਡ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ (Git) ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਂਦੀ ਹੈ।

ਸਹੀ ਐਪਲੀਕੇਸ਼ਨ:

  • ਕੋਡ ਵਿੱਚ ਕਦੇ ਵੀ ਕੁੰਜੀਆਂ ਨੂੰ ਏਮਬੇਡ ਨਾ ਕਰੋ; ਇੱਕ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਜਾਂ ਇੱਕ ਗੁਪਤ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕਰੋ (ਇੱਕ ਸੇਵਾ ਜੋ ਏਨਕ੍ਰਿਪਟਡ ਕੁੰਜੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ)।
  • ਰੋਟੇਸ਼ਨ: ਨਿਯਮਤ ਅੰਤਰਾਲਾਂ 'ਤੇ ਕੁੰਜੀਆਂ ਨੂੰ ਰੀਨਿਊ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਹਰ 90 ਦਿਨਾਂ ਬਾਅਦ); ਜੇਕਰ ਲੀਕ ਹੋਣ ਦਾ ਸ਼ੱਕ ਹੈ, ਤਾਂ ਤੁਰੰਤ ਰੱਦ ਕਰੋ।
  • ਸਕੋਪ ਕਟੌਤੀ: ਹਰੇਕ ਸਵਿੱਚ ਵਿੱਚ ਸਿਰਫ਼ ਲੋੜੀਂਦੀ ਸੇਵਾ ਅਤੇ ਲੋੜੀਂਦਾ ਅਧਿਕਾਰ ਹੁੰਦਾ ਹੈ।
  • ਆਡਿਟ: ਲੌਗ ਕਰੋ ਕਿ ਕਿਸ ਨੇ ਕੁੰਜੀ, ਕਦੋਂ, ਅਤੇ ਕਿੱਥੇ ਵਰਤੀ।

ਚਾਰ ਕਾਪੀ ਕਰਨ ਯੋਗ ਨਮੂਨੇ

ਪਹੁੰਚ ਸਮੀਖਿਆ ਕੰਟਰੋਲ ਪ੍ਰੋਂਪਟ:

ਹੇਠਾਂ ਦਿੱਤੀ ਟੂਲ ਸੂਚੀ ਵਿੱਚ ਹਰੇਕ ਟੂਲ ਲਈ, ਮੁਲਾਂਕਣ ਕਰੋ:- ਕੀ ਇਸ ਸਹਾਇਕ ਦਾ ਕੰਮ ਕਰਨ ਲਈ ਇਸ ਟੂਲ ਦੀ ਲੋੜ ਹੈ? (ਹਾਂ/ਨਹੀਂ) - ਕੀ ਇਹ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਹੈ ਜਾਂ ਲਿਖਣਾ/ਮਿਟਾਉਣਾ ਹੈ? - ਕੀ ਇਸ ਸਾਧਨ ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰ ਜਾਂ ਸੇਵਾ ਖਾਤੇ ਨਾਲ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ? ਬੇਲੋੜੇ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਧਿਕਾਰਤ ਲੋਕਾਂ ਨੂੰ "ਹਟਾਓ/ਰੀਡੈਕਟ" ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰੋ।<tools>{{ tool_list }}</tools>

ਗੁਪਤ ਲੀਕ ਸਕੈਨਿੰਗ ਪ੍ਰੋਂਪਟ:

ਹੇਠਾਂ ਦਿੱਤੇ ਕੋਡ ਸਨਿੱਪਟ ਵਿੱਚ ਕੋਈ ਵੀ ਚੀਜ਼ ਲੱਭੋ ਜੋ ਹਾਰਡਕੋਡਡ ਗੁਪਤ ਹੋ ਸਕਦੀ ਹੈ: API ਕੁੰਜੀ, ਪਾਸਵਰਡ, ਟੋਕਨ, ਕਨੈਕਸ਼ਨ ਸਤਰ, ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ। ਹਰੇਕ ਲਈ ਕਤਾਰ ਦਿਓ ਅਤੇ ਟਾਈਪ ਕਰੋ। ਜਵਾਬ ਵਿੱਚ ਮੁੱਲ ਕਾਪੀ ਕਰੋ;ਮਾਸਕ (ਪਹਿਲੇ 4 ਅੱਖਰ + ***)।<code>{{ ਸਰੋਤ }}</code>

ਸਭ ਤੋਂ ਘੱਟ ਅਥਾਰਟੀ ਫੈਸਲੇ ਦਾ ਨਿਯਮ:

ਜਦੋਂ ਕੋਈ ਨਵਾਂ ਟੂਲ/ਐਕਸੈੱਸ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਪੁੱਛੋ: 1. ਕੀ ਇਸ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? -> ਜੇਕਰ ਹਾਂ: REJECT2। ਕੀ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਕਾਫ਼ੀ ਹੈ? -> ਜੇ ਹਾਂ: ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ3। ਕੀ ਦਾਇਰੇ ਨੂੰ ਇੱਕ ਸਰੋਤ ਤੱਕ ਸੀਮਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? -> ਜੇਕਰ ਹਾਂ: darat ਡਿਫਾਲਟ ਜਵਾਬ "ਨਹੀਂ" ਹੈ; ਪਹੁੰਚ ਕਾਰਨ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.

ਰੋਟੇਸ਼ਨ ਕੈਲੰਡਰ ਰੀਮਾਈਂਡਰ:

ਹਰੇਕ ਗੁਪਤ ਲਈ, ਰਿਕਾਰਡ: ਮਾਲਕ, ਸਿਰਜਣ ਦੀ ਮਿਤੀ, ਮਿਆਦ ਪੁੱਗਣ, ਦਾਇਰਾ। ਕਿਸੇ ਵੀ ਕੁੰਜੀ ਦੀ ਰਿਪੋਰਟ ਕਰੋ ਜੋ 90 ਦਿਨਾਂ ਤੋਂ ਵੱਧ ਗਈ ਹੈ ਜਾਂ "ROTATION/CANCELLATION CANDIDATE" ਵਜੋਂ 30 ਦਿਨਾਂ ਤੋਂ ਵਰਤੀ ਨਹੀਂ ਗਈ ਹੈ।

ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ

ਮਾੜੀ ਪਹੁੰਚ

ਮਜ਼ਬੂਤ ਪਹੁੰਚ

ਮਾਡਲ ਇੱਕ ਸਿੰਗਲ ਸੇਵਾ ਖਾਤੇ ਨਾਲ ਸਾਰੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ

ਮਾਡਲ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਦੇ ਅਧਿਕਾਰ ਨਾਲ ਪਹੁੰਚ ਕਰਦਾ ਹੈ

API ਕੁੰਜੀ ਕੋਡ ਵਿੱਚ ਏਮਬੇਡ ਕੀਤੀ ਗਈ ਹੈ, ਇਹ ਕਦੇ ਨਹੀਂ ਬਦਲਦੀ

ਮੁੱਖ ਗੁਪਤ ਮੈਨੇਜਰ ਵਿੱਚ ਰੋਟੇਸ਼ਨ, 90 ਦਿਨ

ਸਹਾਇਕ ਨੂੰ ਵਿਆਪਕ "ਕੁਝ ਵੀ ਕਰੋ" ਦਾ ਅਧਿਕਾਰ

ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਡਿਫੌਲਟ, ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ ਲਿਖੋ

ਪਹੁੰਚਾਂ ਦੀ ਕਦੇ ਸਮੀਖਿਆ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ

ਨਿਯਮਤ ਪਹੁੰਚ ਸਮੀਖਿਆ ਅਤੇ ਰੱਦ

ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ

ਕੇਸ 1 — ਲੀਕ ਕੀਤਾ ਮਿਸ਼ਰਤ ਪ੍ਰੌਕਸੀ ਡੇਟਾ। ਇੱਕ ਇਨ-ਹਾਊਸ ਸਹਾਇਕ ਇੱਕ ਸੇਵਾ ਖਾਤੇ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਜਿਸ ਕੋਲ ਸਾਰੇ ਕਰਮਚਾਰੀ ਰਿਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਸੀ। ਇੱਕ ਅੰਦਰੂਨੀ ਉਪਭੋਗਤਾ ਨੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਜੋ ਉਹ ਆਮ ਤੌਰ 'ਤੇ "ਕਾਰਜਕਾਰੀ ਤਨਖਾਹ ਸਾਰਣੀ ਨੂੰ ਸੰਖੇਪ ਕਰੋ" ਕਹਿ ਕੇ ਨਹੀਂ ਦੇਖਦਾ ਸੀ; ਕਿਉਂਕਿ ਮਾਡਲ ਨੇ ਇਸਦੇ ਆਪਣੇ ਵਿਆਪਕ ਅਧਿਕਾਰ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸਵਾਲ ਕੀਤਾ, ਨਾ ਕਿ ਉਪਭੋਗਤਾ ਦੇ। ਇੱਕ ਵਾਰ ਉਪਭੋਗਤਾ ਸੰਦਰਭ ਨੂੰ ਮੂਵ ਕਰਨ ਲਈ ਐਡਜਸਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਇੰਟਰਨ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ ਖਿੱਚਣ ਦੇ ਯੋਗ ਸੀ ਜੋ ਸਿਰਫ਼ ਉਹ ਦੇਖ ਸਕਦਾ ਸੀ।

ਕੇਸ 2 — ਲੀਕ ਹੋਈ ਕੁੰਜੀ, 2 ਹਫ਼ਤਿਆਂ ਵਿੱਚ 190,000 TL ਬਿੱਲ। ਇੱਕ ਡਿਵੈਲਪਰ ਨੇ ਇੱਕ ਸਹਾਇਕ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਮਾਡਲ API ਕੁੰਜੀ ਨੂੰ ਏਮਬੈਡ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਜਨਤਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਧੱਕ ਦਿੱਤਾ। ਇੱਕ ਬੋਟ ਨੇ 40 ਮਿੰਟਾਂ ਵਿੱਚ ਕੁੰਜੀ ਲੱਭੀ ਅਤੇ ਇਸਨੂੰ ਦੋ ਹਫ਼ਤਿਆਂ ਲਈ ਵਰਤਿਆ; ਬਿੱਲ 190,000 TL ਤੱਕ ਪਹੁੰਚ ਗਿਆ। ਜਦੋਂ ਕੁੰਜੀ ਨੂੰ ਗੁਪਤ ਮੈਨੇਜਰ ਵਿੱਚ ਭੇਜਿਆ ਗਿਆ ਸੀ, ਰੋਟੇਸ਼ਨ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਸੀ, ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ ਸਕੈਨਿੰਗ ਜੋੜੀ ਗਈ ਸੀ, ਤਾਂ ਘਟਨਾ ਦੁਬਾਰਾ ਨਹੀਂ ਵਾਪਰੀ।

ਕੇਸ 3 — ਰੀਡ-ਓਨਲੀ ਡਿਫੌਲਟ ਰੋਕਿਆ ਗਿਆ ਰੁਕਾਵਟ। ਇੱਕ DevOps ਸਹਾਇਕ ਨੂੰ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਦੁਆਰਾ ਇੱਕ "ਰੀਸੈਟ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ" ਕਮਾਂਡ ਪ੍ਰਾਪਤ ਹੋਈ। ਹਾਲਾਂਕਿ, ਸਹਾਇਕ ਨੂੰ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਟੋਕਨ ਦਿੱਤਾ ਗਿਆ ਸੀ; ਲਿਖਣਾ/ਮਿਟਾਉਣਾ ਇੱਕ ਵੱਖਰੇ ਪ੍ਰਵਾਨਿਤ ਪ੍ਰਵਾਹ ਵਿੱਚ ਸੀ। ਹੁਕਮ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਗਲਤੀ ਨਾਲ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ ਅਤੇ ਇਵੈਂਟ ਨੂੰ ਅਲਾਰਮ ਵਜੋਂ ਲੌਗ ਕੀਤਾ ਗਿਆ ਸੀ; ਕੋਈ ਡਾਟਾ ਖਰਾਬ ਨਹੀਂ ਹੋਇਆ।

ਸੁਝਾਅ: ਇੱਕ ਨਵੀਂ ਪਹੁੰਚ ਬੇਨਤੀ ਲਈ "ਨਹੀਂ" ਨੂੰ ਆਪਣਾ ਡਿਫੌਲਟ ਜਵਾਬ ਬਣਾਓ। ਪਹੁੰਚ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਜਾਇਜ਼ ਠਹਿਰਾਉਣ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਹਰ ਕਿਸੇ ਨੂੰ ਚੌੜਾ ਦੇਣਾ ਅਤੇ ਫਿਰ ਵਾਪਸ ਕੱਟਣਾ ਲਗਭਗ ਕਦੇ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਜੋਖਮ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ

  • ਇੱਕ ਵੱਡੇ ਸੇਵਾ ਖਾਤੇ ਨਾਲ ਮਾਡਲ ਨੂੰ ਚਲਾਉਣਾ ਅਤੇ ਉਪਭੋਗਤਾ ਸੰਦਰਭ (ਮਿਕਸਡ ਪ੍ਰੌਕਸੀ) ਨੂੰ ਗੁਆਉਣਾ।
  • ਏਪੀਆਈ ਕੁੰਜੀ ਨੂੰ ਕੋਡ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਵਿੱਚ ਲੀਕ ਕਰਨਾ।
  • ਕੁੰਜੀਆਂ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਘੁੰਮਾਉਣਾ ("ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਨਾ ਛੂਹੋ")।
  • ਸਹਾਇਕ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਲਿਖਣ/ਮਿਟਾਉਣ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਦੇਣਾ।
  • ਇੱਕ ਵਾਰ ਪਹੁੰਚ ਦੇਣਾ ਅਤੇ ਕਦੇ ਵੀ ਇਸ 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਨਹੀਂ ਕਰਨਾ।
  • ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਉਲਝਾਉਣਾ ਅਤੇ ਇਹ ਮੰਨਣਾ ਕਿ "ਉਸਨੇ ਲੌਗਇਨ ਕੀਤਾ ਹੈ, ਉਹ ਹਰ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ"।

ਸੰਖੇਪ ਵਿੱਚ

  • ਪ੍ਰਮਾਣਿਕਤਾ "ਤੁਸੀਂ ਕੌਣ ਹੋ" ਦਾ ਸਵਾਲ ਹੈ, ਪ੍ਰਮਾਣਿਕਤਾ "ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ" ਦਾ ਸਵਾਲ ਹੈ; AI ਵਿੱਚ, ਦੋਵਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
  • ਮਾਡਲ ਨੂੰ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਦੇ ਅਥਾਰਟੀ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇਸਦੇ ਆਪਣੇ ਵਿਆਪਕ ਅਥਾਰਟੀ ਨਾਲ (ਮਿਕਸਡ ਏਜੰਸੀ ਦੇ ਜੋਖਮ ਤੋਂ ਬਚਣਾ)।
  • RBAC ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ 'ਤੇ ABAC ਨਾਲ ਡੂੰਘਾ ਕਰੋ; ਘੱਟੋ-ਘੱਟ ਅਥਾਰਟੀ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਓ।
  • ਕੋਡ ਵਿੱਚ ਭੇਦ ਨਾ ਦੱਬੋ; ਇਸਨੂੰ ਗੁਪਤ ਮੈਨੇਜਰ ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਇਸਨੂੰ ਤੰਗ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਨਿਯਮਤ ਰੋਟੇਸ਼ਨ ਵਿੱਚ ਪਾਓ।
  • ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਡਿਫੌਲਟ ਅਤੇ ਤੰਗ ਰਾਈਟ ਟੀਕੇ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਬਹੁਤ ਹੱਦ ਤੱਕ ਸੀਮਤ ਕਰਦੇ ਹਨ।

ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ

ਤੁਹਾਡੇ AI ਸਹਾਇਕ ਦੁਆਰਾ ਐਕਸੈਸ ਕਰਨ ਵਾਲੇ ਸਾਰੇ ਟੂਲਸ ਅਤੇ ਡੇਟਾ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਹਰੇਕ ਲਈ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ: (1) ਕੀ ਇਹ ਸੱਚਮੁੱਚ ਜ਼ਰੂਰੀ ਹੈ? (2) ਕੀ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਕਾਫ਼ੀ ਹੈ? (3) ਕੀ ਇਹ ਉਪਭੋਗਤਾ ਸੰਦਰਭ ਵਿੱਚ ਚਲਦਾ ਹੈ? ਫਿਰ ਸਾਰੇ ਹਾਰਡ-ਕੋਡ ਕੀਤੇ ਰਾਜ਼ਾਂ ਦੀ ਖੋਜ ਕਰੋ (ਉਪਰੋਕਤ ਸਕੈਨ ਪ੍ਰੋਂਪਟ ਰਾਹੀਂ) ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲੱਭੀ ਗਈ ਹਰੇਕ ਕੁੰਜੀ ਲਈ ਇੱਕ ਰੋਟੇਸ਼ਨ ਪਲਾਨ ਲਿਖੋ। ਘੱਟੋ-ਘੱਟ ਇੱਕ ਬੇਲੋੜੀ ਅਧਿਕਾਰ ਹਟਾਓ।

ਚੈੱਕਲਿਸਟ

  • [ ] ਮਾਡਲ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਉਪਭੋਗਤਾ ਦੇ ਅਥਾਰਟੀ ਸੰਦਰਭ ਵਿੱਚ ਚੱਲਦਾ ਹੈ।
  • [ ] ਟੂਲ ਅਤੇ ਡੇਟਾ ਐਕਸੈਸ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦੇ ਸਿਧਾਂਤ ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ।
  • [] ਲਿਖੋ/ਮਿਟਾਓ ਸਿਰਫ਼-ਪੜ੍ਹਨ, ਪ੍ਰਮਾਣਿਤ ਅਤੇ ਤੰਗ ਤੋਂ ਵੱਖਰਾ ਹੈ।
  • [ ] ਕੋਡ ਵਿੱਚ ਕੋਈ ਭੇਦ ਦੱਬੇ ਹੋਏ ਨਹੀਂ ਹਨ; ਇਹ ਗੁਪਤ ਮੈਨੇਜਰ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ.
  • ਕੁੰਜੀਆਂ ਲਈ ਇੱਕ ਰੋਟੇਸ਼ਨ ਸਮਾਂ-ਸਾਰਣੀ ਅਤੇ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।
  • [] ਪਹੁੰਚਾਂ ਦੀ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਸਮੀਖਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।