02 ਦਸੰ 2025·8 ਮਿੰਟ
Kevin Mitnick ਦੇ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਸਬਕ ਫਾਉਂਡਰਾਂ ਲਈ
Kevin Mitnick ਦੇ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਸਬਕ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਵੱਧਤਰ ਬ੍ਰੀਚ ਲੋਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਛੇਦ ਹਨ। ਅਮਲੀ ਕਦਮ: least privilege, ਆਡੀਟ ਟ੍ਰੇਲ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ।
Kevin Mitnick ਦੇ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਸਬਕ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਵੱਧਤਰ ਬ੍ਰੀਚ ਲੋਕਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਛੇਦ ਹਨ। ਅਮਲੀ ਕਦਮ: least privilege, ਆਡੀਟ ਟ੍ਰੇਲ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ।
ਜਦੋਂ ਕੋਈ ਬ੍ਰੀਚ ਖ਼ਬਰਾਂ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਸੁਣਾਈ ਦਿੰਦੀ ਹੈ: ਕਿਸੇ ਨੇ ਗਲਤ ਲਿੰਕ 'ਤੇ ਕਲਿਕ ਕੀਤਾ, ਪਾਸਵਰਡ ਸਾਂਝਾ ਕੀਤਾ, ਜਾਂ ਗਲਤ ਬਿਨਤੀ ਮਨਜ਼ੂਰ ਕਰ ਦਿੱਤੀ। ਪਰ ਅਕਸਰ ਇਹ ਪੂਰੀ ਤਸਵੀਰ ਨਹੀਂ ਹੁੰਦੀ।
ਜ਼ਿਆਦਾਤਰ ਸੁਰੱਖਿਆ ਫੇਲਅਰ ਇੱਕ ਮਾਮੂਲੀ ਮਨੁੱਖੀ ਭਰੋਸੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਜੋ ਅਕਸਰ ਔਖੇ ਵਰਕਫਲੋ ਵਿੱਚ ਹੋਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਗਾਰਡਰੇਲ ਪਰਦੇ ਨਹੀਂ ਹੁੰਦੇ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਗਲਤੀ ਨੂੰ ਰੋਕ ਸਕਦੇ ਸਨ।
ਲੋਕ ਆਮ ਤੌਰ ਤੇ ਮਦਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਟੀਮ-mate ਲਾਂਚ ਅਣਬਲੌਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਸਪੋਰਟ ਗ੍ਰਾਹਕ ਨੂੰ ਸ਼ਾਂਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਫਾਇਨੈਂਸ ਇਨਵੌਇਸ ਭੁਗਤਾਨ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਹਮਲਾਵਰ ਠੀਕ ਉਨ੍ਹਾਂ ਪਲਾਂ 'ਤੇ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ। ਜੇ ਪ੍ਰਕਿਰਿਆ ਸਪੱਸ਼ਟ ਨਹੀਂ ਅਤੇ ਪਹੁੰਚ ਖੁੱਲੀ ਹੈ, ਤਾਂ ਇੱਕ ਵਿਸ਼ਵਾਸਯੋਗ ਸੁਨੇਹਾ ਬੜੇ ਨੁਕਸਾਨ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।
ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਆਸਲ ਵਿੱਚ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਹਮਲਾਵਰ ਦਾ ਕੰਮ ਕਰਨ ਲਈ ਮਨਾਉਣ ਦਾ ਇਕ ਨਾਮ ਹੈ। ਇਹ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:
ਇਹ ਗਹਿਰੇ ਹੈਕਿੰਗ, ਮਾਲਵੇਅਰ ਵਿਸ਼ਲੇਸ਼ਣ, ਜਾਂ ਅਜੀਬ ਐਕਸਪਲੋਰਟ ਨਹੀਂ ਹੈ। ਇਹ ਫਾਟਕੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਘਟਾਉਣ ਵਾਲੇ ਅਮਲੀ ਕਦਮ ਹਨ: ਕੰਮ ਦੀ ਪਹੁੰਚ ਘੱਟ ਕਰਨੀ, ਬਿਹਤਰ ਵੇਰਵਾ ਰੱਖਣਾ, ਅਤੇ ਉਹ defaults ਜੋ ਬਲਾਸਟ ਰੇਡੀਅਸ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਹਨ।
ਮਕਸਦ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਸੁਸਤ ਨਹੀਂ ਕਰਨਾ; ਮਕਸਦ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਬਣਾਉਣਾ ਹੈ। ਜਦੋਂ ਅਨੁਮਤੀਆਂ ਸੀਮਤ ਹੁੰਦੀਆਂ ਹਨ, ਕਾਰਵਾਈਆਂ ਲਾਗ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਖਤਰਨਾਕ ਸੈਟਿੰਗ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਬੰਦ ਹੁੰਦੀਆਂ ਹਨ, ਉਝੀ ਮਨੁੱਖੀ ਗਲਤੀ ਇੱਕ ਕੰਪਨੀ-ਪੱਧਰੀ ਸੰਕਟ ਨਹੀਂ ਬਣਦੀ।
Kevin Mitnick ਇਸ ਲਈ ਮਸ਼ਹੂਰ ਹੋਏ ਨਹੀਂ ਕਿ ਉਹ ਕੋਈ ਜਾਦੂਈ ਐਕਸਪਲੋਇਟ ਲਿਖਦੇ ਸਨ, ਪਰ ਇਸ ਲਈ ਕਿ ਉਹ ਦਿਖਾਇਆ ਕਿ ਆਮ ਅਤੇ ਸਮਝਦਾਰ ਲੋਕਾਂ ਨੂੰ ਕਿੰਨਾ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਮੰਨਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ ਦੀ ਕਹਾਣੀ ਧੋਖਾ, ਮਨਾਉਣਾ, ਅਤੇ ਉਹ ਪ੍ਰਕਿਰਿਆ ਗੈਪ ਵਿਖਾਉਂਦੀ ਹੈ ਜੋ ਟੀਮਾਂ ਉਦਯੋਗ ਵਿੱਚ ਰਹਿਣ ਦੌਰਾਨ ਅਣਡਿੱਠੇ ਰਹਿ ਜਾਂਦੇ ਹਨ।
ਸਿੱਖਣ ਯੋਗ ਗੱਲ ਸਧਾਰਨ ਹੈ: ਹਮਲਾਵਰ ਅਕਸਰ ਸਭ ਤੋਂ ਮੁਸ਼ਕਿਲ ਨਿਸ਼ਾਨਾ ਨਹੀਂ ਲੈਂਦੇ। ਉਹ ਤੁਹਾਡੇ ਕੰਪਨੀ ਵਿੱਚ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਲਭਦੇ ਹਨ, ਜੋ ਅਕਸਰ ਉਹ ਵਿਅਕਤੀ ਹੁੰਦਾ ਹੈ ਜੋ ਜਲਦੀ ਵਿੱਚ, ਮਦਦਗਾਰ, ਜਾਂ ਨਹੀਂ ਜਾਣਦਾ ਕਿ “ਆਮ” ਕੀ ਹੈ।
ਇਸ ਨਾਲ ਇਕ ਆਮ ਮਿਥ ਵੀ ਸਾਫ਼ ਹੁੰਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਬ੍ਰੀਚ “ਜੀਨੀਅਸ ਕੋਡ ਬ੍ਰੇਕਿੰਗ” ਨਹੀਂ ਹੁੰਦੇ ਜਿਥੇ ਕੋਈ ਲਾਮਬਾ ਤਵੱਕਰ ਕਰ ਕੇ ਸਰੂਪ ਨੂੰ ਤੋੜਦਾ ਹੈ। ਅਕਸਰ ਇਹ ਬੁਨਿਆਦੀ ਹਨ: ਇਕੋ ਪੁਛਰ ਪਾਸਵਰਡਾਂ ਦੀ ਵਰਤੋਂ, ਸਾਂਝੇ ਖਾਤੇ, ਅਨੁਮਤੀਆਂ ਜੋ ਕਦੇ ਹਟਾਈਆਂ ਹੀ ਨਹੀਂ ਗਈਆਂ, ਜਾਂ ਕੋਈ ਮਨਜ਼ੂਰ ਹੋ ਕੇ ਕਿਸੇ ਕਦਮ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਫਾਉਂਡਰ ਬਿਨਾਂ ਕੰਪਨੀ ਨੂੰ ਕਿਲ੍ਹਾ ਬਣਾਏ ਨੁਕਸਾਨ ਘਟਾ ਸਕਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਪੈਰਾਨੋਆ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ ਗਾਰਡਰੇਲ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਇਕ ਮਾੜਾ ਫੈਸਲਾ ਪੂਰੇ ਬ੍ਰੀਚ ਵਿੱਚ ਨਹੀਂ ਬਦਲੇ।
ਤੀਨ ਕੰਟਰੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਆਮ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਜਿੱਤਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ:
ਇਹ ਜਾਣ-ਪਛਾਣ ਲਈ ਬੋਰਿੰਗ ਹਨ। ਬੋਰਿੰਗ ਧੋਖੇਬਾਜ਼ੀ ਨੂੰ ਰੋਕਦਾ ਹੈ।
Mitnick ਦੇ ਸਬਕ ਫਾਉਂਡਰਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ “ਹਮਲਾ” ਅਕਸਰ ਸਧਾਰਨ ਦਿਨ ਵਰਗਾ ਲੱਗਦਾ ਹੈ: ਕਿਸੇ ਨੂੰ ਮਦਦ ਦੀ ਲੋੜ, ਕੁਝ ਅਤਿ-ਜ਼ਰੂਰੀ, ਅਤੇ ਤੁਸੀਂ ਕੰਮ ਜਾਰੀ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਮਦਦਗਾਰ ਪਲਾਂ 'ਚ ਹੁੰਦੀਆਂ ਹਨ। “ਮੈਂ ਲਾਕ ਆਊਟ ਹਾਂ, ਕੀ ਤੁਸੀਂ ਮੇਰਾ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰ ਸਕਦੇ ਹੋ?” “ਡੈਮੋ ਤੋਂ ਪੰਜ ਮਿੰਟ ਪਹਿਲਾਂ ਡ੍ਰਾਈਵ ਨਹੀਂ ਖੁਲ ਰਿਹਾ।” “ਇਸ ਗ੍ਰਾਹਕ ਨੂੰ ਅੱਜ ਬਿਲਿੰਗ ਬਦਲਣੀ ਹੈ।” ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਵੈ-ਵਿਚਾਰ ਕਰਨਯੋਗ ਨਹੀਂ ਹੁੰਦਾ।
ਛੋਟੀ ਟੀਮਾਂ ਵੀ ਅਨौਪਚਾਰਿਕ ਤਰੀਕੇ ਨਾਲ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀਆਂ ਹਨ। ਪਹੁੰਚ DMs ਵਿੱਚ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਇੱਕ ਛੋਟੀ ਕਾਲ 'ਤੇ, ਜਾਂ ਹਾਲਵੇ 'ਤੇ ਪੁੱਛਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਤੇਜ਼ੀ ਆਪ ਵਿੱਚ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਸਮੱਸਿਆ ਇਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ “ਜੋ ਵੀ ਸੁਨੇਹਾ ਪਹਿਲਾਂ ਵੇਖਦਾ ਹੈ ਉਹ ਕੰਮ ਕਰਦਾ ਹੈ” ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਜ਼ ਦੀ ਉਮੀਦ ਹੁੰਦੀ ਹੈ।
ਕੁਝ ਭੂਮਿਕਾਵਾਂ ਵੱਧ ਨਿਸ਼ਾਨਾ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਜਲਦੀ “ਹਾਂ” ਕਹਿ ਸਕਦੀਆਂ ਹਨ: ਫਾਉਂਡਰ ਅਤੇ ਐਗਜ਼ੈਕਟਿਵ, ਫਾਇਨੈਂਸ, ਸਪੋਰਟ, DevOps ਜਾਂ IT ਐਡਮਿਨ, ਅਤੇ ਕੋਈ ਵੀ ਜਿਸਦੇ ਕੋਲ ਈਮੇਲ, ਕਲਾਉਡ, ਜਾਂ ਕੋਡ ਹੋਸਟਿੰਗ 'ਚ ਐਡਮਿਨ ਅਧਿਕਾਰ ਹਨ।
ਸਧਾਰਨ ਉਦਾਹਰਨ: ਇੱਕ “ਠੇਕੇਦਾਰ” ਰਾਤ ਨੂੰ ਦੇਰ ਨੂੰ ਫਾਉਂਡਰ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ ਕਿ ਓਹ ਪ੍ਰੋਡਕਸ਼ਨ ਪਹੁੰਚ ਚਾਹੁੰਦਾ ਹੈ “ਲਾਂਚ ਮੁੱਦੇ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ।” ਫਾਉਂਡਰ ਮਦਦ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, DevOps ਨੂੰ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਬਿਨਤੀ ਬਿਨਾ ਦੂਜੇ ਜਾਂਚ ਦੇ ਮਨਜ਼ੂਰ ਹੋ ਜਾਂਦੀ ਹੈ।
ਗਤੀ ਨੂੰ ਬਣਾਈ ਰੱਖੋ, ਪਰ ਗਾਰਡਰੇਲ ਜੋੜੋ: ਦੂਜੇ ਚੈਨਲ ਵਿੱਚ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਲਿਖਤੀ ਬਿਨਤੀ ਇੱਕ ਹੀ ਥਾਂ 'ਤੇ ਮੰਗੋ, ਅਤੇ “ਤੁਰੰਤ” ਪਹੁੰਚ ਲਈ ਸਪੱਸ਼ਟ ਨਿਯਮ ਰੱਖੋ ਤਾਂ ਕਿ ਜ਼ਰੂਰਤ ਸੁਰੱਖਿਆ ਉੱਤੇ ਭਾਰੀ ਨਾ ਪਏ।
ਬਹੁਤ ਸਾਰੀਆਂ ਸਟਾਰਟਅੱਪ ਸੁਰੱਖਿਆ ਲਾਪਰਵਾਹੀਆਂ ਕਿਸੇ ਨੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤੋੜ ਕੇ ਨਹੀਂ ਕਰਦੀਆਂ। ਓਹ ਉਦੋਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਇੱਕ ਆਮ ਵਰਕਫਲੋ ਵਿੱਚ ਛੇਦ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਚੀਜ਼ ਇੱਕ ਬੁਰਾ ਬਿਨਤੀ, ਇੱਕ ਜਲਦੀ ਮਨਜ਼ੂਰੀ, ਜਾਂ ਇੱਕ ਪੁਰਾਣਾ ਖਾਤਾ ਜੋ ਬੰਦ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਨੂੰ ਰੋਕਣ ਲਈ ਨਹੀਂ ਹੁੰਦਾ।
ਪ੍ਰਕਿਰਿਆ ਗੈਪ ਅਕਸਰ ਓਸ ਦਿਨ ਤੱਕ ਅਦਿੱਖੇ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤੁਸੀਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਂਦੇ ਹਨ:
ਟੂਲਿੰਗ ਗੈਪ ਗਲਤੀਆਂ ਮਹਿੰਗੀਆਂ ਬਣਾਂਦੇ ਹਨ। ਸਾਂਝੇ ਖਾਤੇ ਇਹ ਛੁਪਾ ਦੇਂਦੇ ਹਨ ਕਿ ਕਿਸਨੇ ਕੀ ਕੀਤਾ। ਅਨੁਮਤੀਆਂ ਸਮੇਂ ਨਾਲ ਗੰਦੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਬਿਨਾ ਕੇਂਦਰੀ ਲੌਗਸ ਦੇ, ਤੁਸੀਂ ਨਹੀਂ ਪਤਾ ਸਕਦੇ ਕਿ “ਉਪਦ੍ਰਵ” ਇਕ ਦੋਸ਼ ਸੀ ਜਾਂ ਕੁਝ ਹੋਰ।
ਸੱਭਿਆਚਾਰ ਵੀ ਅੰਤਿਮ ਧੱਕਾ ਦੇ ਸਕਦਾ ਹੈ। “ਅਸੀਂ ਹਰ ਕਿਸੇ ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਾਂ” ਸਹੀ ਹੈ, ਪਰ ਇਹ ਚੱਪਚਾਪ “ਅਸੀਂ ਕਦੇ ਪਰਖੀ ਨਹੀਂ ਕਰਦੇ” ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। ਦੋਸਤੀਭਰਿਆ ਟੀਮ ਹੀ ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਨਿਸ਼ਾਨਾ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਵਿਨਮਰਤਾ ਅਤੇ ਤੇਜ਼ੀ ਡਿਫਾਲਟ ਬਣ ਜਾਂਦੇ ਹਨ।
ਸਧਾਰਨ ਗਾਰਡਰੇਲ ਸਭ ਤੋਂ ਵੱਡੇ ਛੇਦ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਭਾਰੀ ਬਣਾਉਣ ਦੇ:
ਇੱਕ ਗਲਤ ਮਨਜ਼ੂਰੀ ਵਧੀਆ ਟੈਕਨੀਕਲ ਸੁਰੱਖਿਆ ਨੂੰ ਵੀ ਬਾਇਪਾਸ ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਕੋਈ “ਅਸਥਾਈ ਪਹੁੰਚ” ਵਿਚ ਗੱਲਬਾਤ ਕਰਕੇ ਮਿਲ ਸਕਦੀ ਹੈ, ਤਾਂ ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ ਨੀਤੀ ਤੁਹਾਨੂੰ ਬਚਾ ਨਹੀਂ ਸਕਦੀ।
Least privilege ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਹੈ: ਲੋਕਾਂ ਨੂੰ ਉਹੀ ਘੱਟੋ-ਘੱਟ ਪਹੁੰਚ ਦਿਓ ਜੋ ਉਹ ਅਜਿਹਾ ਕੰਮ ਕਰਨ ਲਈ ਤੁਰੰਤ ਲੋੜੀਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆ
ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਮਲਾਵਰਾਂ ਨੂੰ ਕੁਝ “ਹੈਕ” ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ ਜੇ ਉਹ ਕਿਸੇ ਨੂੰ ਮਨਾਉ ਲੈਂਦੇ ਹਨ ਕਿ ਉਹ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਪਹੁੰਚ ਵਰਤੇ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪਹੁੰਚ ਨੂੰ ਦਿਖਾਓ। ਨੌਜਵਾਨ ਕੰਪਨੀ ਵਿੱਚ ਅਧਿਕਾਰ ਸ਼ਾਂਤ ਰੂਪ ਨਾਲ ਵੱਧ ਜਾਂਦੇ ਹਨ ਜਦ ਤੱਕ “ਸਭ ਕੁਝ ਕਰ ਸਕਦੇ” ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਘੰਟਾ ਲਵੋ ਅਤੇ ਲਿਖੋ ਕਿ ਕੌਣ ਵੱਡੇ ਖੇਤਰਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ: ਪ੍ਰੋਡਕਸ਼ਨ, ਬਿਲਿੰਗ, ਯੂਜ਼ਰ ਡੇਟਾ, ਅੰਦਰੂਨੀ ਐਡਮਿਨ ਟੂਲ, ਕਲਾਉਡ ਖਾਤੇ, ਅਤੇ ਜੋ ਕੁਝ ਵੀ ਕੋਡ ਡਿਪਲੋਇ ਜਾਂ ਐਕਸਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ।
ਫਿਰ ਕੁਝ ਸਪੱਸ਼ਟ ਰੋਲ ਨਾਲ ਪਹੁੰਚ ਘਟਾਓ। ਤੁਹਾਨੂੰ ਪਰਫੈਕਟ ਨੀਤੀ ਦੀ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ ਡਿਫਾਲਟ ਚਾਹੀਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਕੰਮ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਉਦਾਹਰਨ ਵਜੋਂ:
ਸੰਵੇਦਨਸ਼ੀਲ ਟਾਸਕਾਂ ਲਈ ਸਥਾਈ “ਸਿਰਫ਼ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ” ਐਡਮਿਨ ਤੋਂ ਬਚੋ। ਸਮੇਂ-ਬੰਨ੍ਹੇ ਇਊਗ ਉਤ੍ਹਾਹੋ: ਅਸਥਾਈ ਅਧਿਕਾਰ ਜੋ ਆਪਣੇ-ਆਪ ਹੀ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ।
ਆਫ਼ਬੋਰਡਿੰਗ ਇਸਤੋਂ ਜ਼ਿਆਦਾ ਕਦੇ-ਕਦੇ ਟੁੱਟਦਾ ਹੈ। ਜੇ ਕੋਈ ਲੁੱਕ-ਆਉਟ ਜਾਂ ਰੋਲ ਬਦਲਦਾ ਹੈ, ਉਸੇ ਦਿਨ ਪਹੁੰਚ ਹਟਾਓ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਸਾਂਝੀ ਰਾਜ਼ (ਜਿਵੇਂ shared passwords, team API keys) ਹਨ, ਉਹਨਾਂ ਨੂੰ ਫੌਰਨ ਰੀੋਟੇਟ ਕਰੋ। ਇੱਕ ਪੁਰਾਣਾ ਖਾਤਾ ਜਿਸਦੇ ਕੋਲ ਵਿਆਪਕ ਅਧਿਕਾਰ ਹਨ, ਹਰ ਹੋਰ ਸੁਰੱਖਿਆ ਫੈਸਲੇ ਨੂੰ ਨਰਸਾ ਦੇ ਸਕਦਾ ਹੈ।
ਆudit trail ਉਹ ਰਿਕਾਰਡ ਹੈ ਕਿ ਕਿਸਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕਿੱਥੋਂ ਤੋਂ। ਇਹ “ਕੁਝ ਹੋਇਆ” ਨੂੰ ਇੱਕ ਟਾਈਮਲਾਈਨ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਵਰਤਾਰਾ ਭੀ ਬਦਲਦਾ ਹੈ: ਜਦੋਂ ਕਾਰਵਾਈਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਲੋਕ ਜ਼ਿਆਦਾ ਸੰਭਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹਨ।
ਛੋਟੇ ਸੈੱਟ ਦੇ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਘਟਨਾਵਾਂ ਨੂੰ ਲੌਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਕੁਝ ਲੌਗ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਡੇਟਾ ਨੂੰ ਹਿਲਾ ਸਕਦੀਆਂ ਹਨ:
ਰਿਟੇੰਸ਼ਨ ਵਿਂਡੋ ਆਪਣੇ ਗਤੀਅਨੁਸਾਰ ਰੱਖੋ। ਕਈ ਸਟਾਰਟਅੱਪ ਤੇਜ਼ ਰਿਸਕ ਸਿਸਟਮਾਂ ਲਈ 30 ਤੋਂ 90 ਦਿਨ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਬਿਲਿੰਗ/ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ ਲਈ ਲੰਬਾ ਰੱਖਦੇ ਹਨ।
ਇੱਥੇ ਮਾਲਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਆਦਮੀ ਨੂੰ ਨਿਰਧਾਰਿਤ ਜਿੰਮੇਵਾਰੀ ਦਿਓ ਜੋ ਹਫਤੇ ਨੂੰ 10 ਮਿੰਟ ਵਰਗਾ ਇਕ ਹਲਕਾ ਸਮੀਖਿਆ ਕਰੇ — ਐਡਮਿਨ ਬਦਲਾਅ ਅਤੇ ਐਕਸਪੋਰਟਾਂ ਦੀ ਜਾਂਚ।
ਅਲਰਟਾਂ ਸ਼ਾਂਤ ਪਰ ਤੇਜ਼ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਕੁਝ ਉੱਚ-ਖਤਰਾ ਟ੍ਰਿੱਗਰ ਬੇਸ਼ੁਮਾਰ ਸ਼ੋਰਗੁਲ ਵਾਲੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਤੋਂ ਵਧੀਆ ਹਨ: ਨਵਾਂ ਐਡਮਿਨ ਬਣਿਆ, ਅਨੁਮਤੀਆਂ ਵੱਧੀਆਂ, ਅਸਮਾਨਯ ਕਰਨ ਵਾਲਾ ਐਕਸਪੋਰਟ, ਨਵੀਂ ਦੇਸ਼ ਤੋਂ ਲੌਗਿਨ, ਬਿਲਿੰਗ ਈਮੇਲ ਬਦਲੀ ਗਈ।
ਪ੍ਰਾਈਵੇਸੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦਾ ਆਦਰ ਕਰੋ। ਕਾਰਵਾਈਆਂ ਅਤੇ ਮੈਟਾ ਡੇਟਾ (ਅਕਾਊਂਟ, ਟਾਈਮਸਟੈਂਪ, IP, ਡਿਵਾਈਸ, ਐਂਡਪਾਇੰਟ) ਲੋਗ ਕਰੋ, ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਨਹੀਂ। ਲੌਗ ਦੇਖਣ ਵਾਲਿਆਂ ਲਈ ਉਹਨਾਂ 'ਤੇ ਉਹੀ ਧਿਆਨ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਪਹੁੰਚ ਲਈ ਰੱਖਦੇ ਹੋ।
“Safer defaults” ਉਹ ਸ਼ੁਰੂਆਤੀ ਸੈਟਿੰਗ ਹਨ ਜੋ ਨੁਕਸਾਨ ਘਟਾਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਗਲਤ ਚੀਜ਼ ਕਲਿੱਕ ਕਰਦਾ, ਗਰੀਬ ਸੁਨੇਹਾ ਮੰਨ ਲੈਂਦਾ, ਜਾਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਘਟਨਾਵਾਂ ਮੂਵੀ-ਸਟਾਈਲ ਹੈਕ ਨਹੀਂ ਹੁੰਦੀਆਂ; ਉਹ ਦਬਾਅ ਵਾਲੇ ਆਮ ਕੰਮ ਹੁੰਦੇ ਹਨ ਜੋ ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਨਿਰਦੇਸ਼ਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਵਧੀਆ ਡਿਫਾਲਟ ਇਸ ਗੱਲ ਦੀ ਮਨੋਵਿਰਤੀ ਰੱਖਦੇ ਹਨ ਕਿ ਮਨੁੱਖ ਥੱਕ ਜਾਂਦੇ ਹਨ, ਬਿਜੀ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਦੇ-ਕਦੇ ਠੱਗੇ ਵੀ ਜਾ ਸਕਦੇ ਹਨ। ਇਹ ਸੁਰੱਖਿਅਤ ਰਸਤੇ ਨੂੰ ਆਸਾਨ ਰਸਤਾ ਬਣਾਉਂਦੇ ਹਨ।
ਜੇਹੜੇ ਡਿਫਾਲਟ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ:
ਉਹ ਕਾਰਵਾਈਆਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ, ਉਨ੍ਹਾਂ 'ਤੇ ਆਮ “ਕੀ-ਕੀ?” ਪੈਟਰਨ ਜੋੜੋ: ਭੁਗਤਾਨ, ਅਨੁਮਤੀ ਬਦਲਾਅ, ਅਤੇ ਵੱਡੇ ਐਕਸਪੋਰਟ ਦੋ ਕਦਮ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਰਤਣ। ਪੁਸਤਾਵਾਂ, ਇਕ ਪੁਸ਼ਟੀ ਤੇ ਦੂਜੀ ਫੈਕਟਰ ਜਾਂ ਦੂਜਾ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਹੋਵੇ।
ਇੱਕ ਹਕੀਕਤੀ ਪਲ ਦੀ ਕਲਪਨਾ ਕਰੋ: ਇੱਕ ਫਾਉਂਡਰ ਨੂੰ Slack 'ਤੇ ਇੱਕ ਸੁਨੇਹਾ ਆਉਂਦਾ ਹੈ ਜੋ ਲੱਗਦਾ ਹੈ ਕਿ ਫਾਇਨੈਂਸ ਵੱਲੋਂ ਹੈ ਅਤੇ ਉਹ “ਤਨਖ਼ਾਹ ਠੀਕ ਕਰਨ ਲਈ” ਇੱਕ ਤੁਰੰਤ ਐਡਮਿਨ ਗ੍ਰਾਂਟ ਚਾਹੁੰਦੇ ਹਨ। ਜੇ ਡਿਫਾਲਟ ਘੱਟ-ਪ੍ਰਿਵਿਲੇਜ ਹੈ ਅਤੇ ਐਡਮਿਨ ਗ੍ਰਾਂਟ ਲਈ ਦੂਜੀ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਵੱਡਾ ਨਤੀਜਾ ਇੱਕ ਅਸਫਲ ਬਿਨਤੀ ਹੋਵੇਗਾ, ਨਾ ਕਿ ਇੱਕ ਬ੍ਰੀਚ।
ਇਹ ਡਿਫਾਲਟ ਸਾਧੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ ਇਹ ਦਿੱਸਣ ਲਈ ਕਿ ਕਿਉਂ; ਜਦੋਂ ਲੋਕ ਝੱਕਣੇ ਦੀ ਵਜ੍ਹਾ ਸਮਝ ਲੈਂਦੇ ਹਨ, ਉਹ ਸਮੇਂ 'ਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਬਾਇਪਾਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਘੱਟ ਕਰਦੇ ਹਨ।
ਫਾਉਂਡਰ-ਕੈਥੇ ਸੁਰੱਖਿਆ ਯੋਜਨਾਵਾਂ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਇਕੱਠਾ ਸਭ ਕੁਝ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਬਿਹਤਰ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਜਿਸ ਇਕ ਵਿਅਕਤੀ ਦੇ ਕੋਲ ਵੱਧ ਪਹੁੰਚ ਹੈ ਉਸ ਨੂੰ ਘੱਟ ਕਰੋ, ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਨੂੰ ਦਿਖਾਈ ਦਿਓ, ਅਤੇ ਓਥੇ ਹੀ friction ਜੋੜੋ ਜਿੱਥੇ ਲੋੜ ਹੈ।
ਦਿਨ 1-7: ਜੋ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹੈ ਉਹ ਪਛਾਣੋ। ਆਪਣੀਆਂ “crown jewels” ਲਿਖੋ: ਗਾਹਕ ਡੇਟਾ, ਜੋ ਕੁਝ ਪੈਸਾ ਚਲਾਉਂਦਾ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਪਹੁੰਚ, ਅਤੇ ਤੁਹਾਡੀ ਉਪਸਥਿਤੀ ਦੀਆਂ ਕੁੰਜੀਆਂ (ਡੋਮੇਨ, ਈਮੇਲ, ਐਪ ਸਟੋਰ)। ਇਸਨੂੰ ਇੱਕ ਸਫ਼ੇ ਰੱਖੋ।
ਦਿਨ 8-14: ਰੋਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਪਹੁੰਚ ਕਸੋ। 3-5 ਰੋਲ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ (Founder, Engineer, Support, Finance, Contractor). ਹਰ ਰੋਲ ਨੂੰ ਸਿਰਫ ਜੋ ਲੋੜੀਦਾ ਹੈ ਦਿੱਤਾ ਜਾਵੇ। ਜੇ ਕਿਸੇ ਨੂੰ ਵੱਧ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ, ਉਹ ਸਮੇਂ-ਬੰਨ੍ਹੀ ਹੋਵੇ।
ਦਿਨ 15-21: ਪ੍ਰਮਾਣਿਕਤਾ ਦੀਆਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਠੀਕ ਕਰੋ। ਸਥਿਤਿਤ ਸਿਸਟਮਾਂ 'ਤੇ MFA ਓਨ ਕਰੋ, ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਉਸ ਨੂੰ ਈਮੇਲ, ਪਾਸਵਰਡ ਮੈਨੇਜਰ, ਕਲਾਉਡ, ਅਤੇ ਭੁਗਤਾਨ ਸਿਸਟਮ ਲਈ ਕਫ਼ੀਰਦਾਰ ਬਣਾਓ। ਸਾਂਝੇ ਖਾਤਿਆਂ ਅਤੇ ਜਨਰਿਕ ਲੌਗਿਨ ਨੂੰ ਹਟਾਓ। ਜੇ ਕੋਈ ਟੂਲ ਸਾਂਝਾ ਕਰਨ ਨੂੰ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਉਸਨੂੰ ਖਤਰੇ ਰੂਪ ਵਿੱਚ ਲੈ ਕੇ ਵਿਕਲਪ ਸੋਚੋ।
ਦਿਨ 22-30: ਦਿੱਖ ਅਤੇ ਮਨਜ਼ੂਰੀਆਂ ਜੁੜੋ। ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਲਈ ਲੌਗ ਐਨਾਬਲ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖੋ ਜਿਸਦੀ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜਾਂਚ ਕਰੋ। ਸਭ ਤੋਂ ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ (ਪੈਸਾ, ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਐਕਸਪੋਰਟ, ਡੋਮੇਨ ਬਦਲਾਅ) ਲਈ ਦੋ-ਪਹਿਰੂ ਮਨਜ਼ੂਰੀ ਸ਼ਾਮਲ ਕਰੋ।
ਅਲਰਟਾਂ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਘੱਟ ਰੱਖੋ:
30 ਦਿਨ ਤੋਂ ਬਾਅਦ, ਦੋ ਦੁਹਰਾਵਾਂ ਵਾਲੀ ਆਈਟਮ ਕੈਲੇਂਡਰ 'ਤੇ ਜੋੜੋ: ਮਹੀਨਵਾਰ ਪਹੁੰਚ ਸਮੀਖਿਆ (ਕੌਣ ਕੋਲ ਕੀ ਹੈ ਅਤੇ ਕਿਉਂ), ਅਤੇ ਤਿਮਾਹੀ ਆਫ਼ਬੋਰਡਿੰਗ ਡ੍ਰਿਲ (ਕੀ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪੂਰੀ ਪਹੁੰਚ ਹਟਾ ਸਕਦੇ ਹੋ, ਟੋਕਨ ਅਤੇ ਡਿਵਾਈਸ ਸਮੇਤ)।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਡਕਟ ਬਣਾਉਂਦੇ ਹੋ ਜਿਵੇਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ, ਤਾਂ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਇਮੈਂਟ, ਅਤੇ ਕਸਟਮ ਡੋਮੇਨ ਵੀ crown-jewel ਕਾਰਵਾਈਆਂ ਹਨ; ਉਨ੍ਹਾਂ ਲਈ ਮਨਜ਼ੂਰੀ ਅਤੇ ਲੌਗਿੰਗ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਜੋੜੋ, ਅਤੇ ਜਲਦੀ ਕੀਤੇ ਬਦਲਾਅ ਨੂੰ ਵਾਪਸ ਕਰਨ ਲਈ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਰੱਖੋ।
ਜ਼ਿਆਦਾਤਰ ਸਟਾਰਟਅੱਪ ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਚਤੁਰਾਈ ਹੋਏ ਹੈਕ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਆਦਤਾਂ ਹਨ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਚਲਣ ਵੇਲੇ ਨਾਰਮਲ ਲੱਗਦੀਆਂ ਹਨ, ਪਰ ਇਕ ਗਲਤ ਸੁਨੇਹੇ ਜਾਂ ਕਲਿੱਕ ਨਾਲ ਮਹਿੰਗੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਆਮ ਫਿਸਲਨ ਇਹ ਹੈ ਕਿ ਐਡਮਿਨ ਪਹੁੰਚ ਡੀਫਾਲਟ ਮੰਨੀ ਜਾਂਦੀ ਹੈ। ਮੁਹਿੰਨਿਆਂ ਵਿੱਚ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਹਰ ਸਮਾੰਧਿਤ ਖਾਤੇ ਨੂੰ ਇੱਕ ਮਾਸਟਰ ਕੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਹੀ ਰੁਝਾਨ ਸਾਂਝੇ ਆਈਡੀਟਿਫਿਕੇਸ਼ਨ, “ਅਸਥਾਈ” ਪਹੁੰਚ ਜੋ ਕਦੇ ਹਟਾਈ ਨਹੀਂ ਜਾਂਦੀ, ਅਤੇ ਥੇਕੇਦਾਰਾਂ ਨੂੰ ਕਰਮਚਾਰੀਆਂ ਵਾਲੀ ਹੀ ਪਹੁੰਚ ਦੇਣ ਵਿੱਚ ਵੀ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ।
ਹੋਰ ਫਿਸਲਨ urgency ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਦੇ ਬਿਨਤੀ ਮਨਜ਼ੂਰ ਕਰਨਾ ਹੈ। ਹਮਲਾਵਰ ਅਕਸਰ ਫਾਉਂਡਰ, ਨਵੀਂ ਭਰਤੀ, ਜਾਂ ਵੈਂਡਰ ਬਣਕੇ ਈਮੇਲ, ਚੈਟ, ਜਾਂ ਫੋਨ ਰਾਹੀਂ ਆਪਣੀ ਨਕਲ ਕਰਦੇ ਹਨ ਅਤੇ ਛੂਟ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਪ੍ਰਕਿਰਿਆ “ਜੇ ਇਹ ਤੁਰੰਤ ਲੱਗਦਾ ਹੈ ਤਾਂ ਕਰ ਦਿਓ” ਹੈ, ਤਾਂ ਉਸ ਵੇਲੇ ਕੌਈ ਰੁਕਾਵਟ ਨਹੀਂ ਰਹਿੰਦੀ ਜਦੋਂ ਕਿਸੇ ਨੂੰ ਨਕਲ ਕੀਤਾ ਜਾਵੇ।
ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਿਖਿਆ देना ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਸਿਖਿਆ ਇੱਕ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੈ। ਜੇ ਵਰਕਫਲੋ ਵਾਪਸ ਉਹੀ ਤੇਜ਼ੀ ਨੂੰ ਇਨਾਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਲੋਕ ਉਦੋਂ ਇਸ ਸਬਕ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਲੌਗਿੰਗ ਵੀ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਹੋ ਜਾਂਦੀ ਹੈ। ਟੀਮਾਂ ਜਾਂ ਤਾਂ ਬਹੁਤ ਘੱਟ ਸੰਭਾਲਦੀਆਂ ਹਨ, ਜਾਂ ਸਾਰਾ ਇਕੱਠਾ ਕਰ ਲੈਂਦੀਆਂ ਹਨ ਪਰ ਫਿਰ ਕਦੇ ਨਹੀਂ ਦੇਖਦੀਆਂ। ਸ਼ੋਰ ਵਾਲੇ ਅਲਰਟ ਲੋਕਾਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਾਉਂਦੇ ਹਨ। ਉਹ ਚੀਜ਼ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਉਹ ਹੈ ਇੱਕ ਛੋਟੀ-ਜਿਹੀ ਘਟਨਾ ਦੀ ਸੈਟ ਜੋ ਤੁਸੀਂ ਅਸਲ میں ਸਮੀਖਿਆ ਅਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਨਾਨ-ਪ੍ਰੋਡਕਸ਼ਨ ਖਤਰਾ ਵੀ ਭੁੱਲੋ ਨਾ। ਸਟੇਜਿੰਗ, ਸਪੋਰਟ ਡੈਸ਼ਬੋਰਡ, ਐਨਾਲਿਟਿਕਸ ਐਕਸਪੋਰਟ, ਅਤੇ ਨਕਲ ਕੀਤੀਆਂ ਡੇਟਾਬੇਸ ਅਕਸਰ ਅਸਲ ਗਾਹਕ ਡੇਟਾ ਰੱਖਦੇ ਹਨ ਪਰ ਕਮਜ਼ੋਰ ਕੰਟਰੋਲ ਹੁੰਦੇ ਹਨ।
ਪੰਜ ਲਾਲ ਝੰਡੀਆਂ ਜੋ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨ ਯੋਗ ਹਨ:
ਹਮਲਾਵਰਾਂ ਨੂੰ ਅੰਦਰ ਆਉਣ ਲਈ ਟੋੜ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਜੇ ਉਹ ਕਿਸੇ ਨੂੰ ਮਨਾਉ ਸਕਦੇ ਹਨ, ਅਤੇ ਛੋਟੇ ਪ੍ਰਕਿਰਿਆ ਗੈਪ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਪੰਜ ਜਾਂਚਾਂ ਕੁੱਝ ਘੰਟਿਆਂ 'ਚ ਹੋ ਜਾਣਗੀਆਂ, ਕੋਈ ਪੂਰਾ ਸੁਰੱਖਿਆ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਟੂਲ ਬਣਾਂਦੇ ਹੋ ਜੋ ਕੋਡ, ਡੇਟਾ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਆਪਣੀ ਪਹੁੰਚ ਰੱਖ ਸਕਦੇ ਹਨ, ਤਾਂ ਇਹ ਗਾਰਡਰੇਲ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇੱਕ ਕਬਜ਼ੇ ਵਾਲਾ ਖਾਤਾ ਮਿੰਟਾਂ ਵਿੱਚ ਇਹਨਾਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ।
ਰਾਤ 6:20 ਵਜੇ — ਡੈਮੋ ਤੋਂ ਇੱਕ ਰਾਤ ਪਹਿਲਾਂ। ਟੀਮ ਚੈਟ 'ਤੇ ਸੁਨੇਹਾ ਆਉਂਦਾ: “ਹੈਲੋ, ਮੈਂ ਨਵਾਂ ਠੇਕੇਦਾਰ ਹਾਂ ਅਤੇ payment bug ਦੂਰ ਕਰਨ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਐਕਸੈਸ ਚਾਹੀਦਾ ਹੈ। ਮੈਂ 20 ਮਿੰਟ ਵਿੱਚ ਠੀਕ ਕਰ ਦੇਵਾਂਗਾ।” ਨਾਮ ਪਹਿਲਾ ਕਿਸੇ ਥਰੇਡ ਵਿੱਚ ਉਲੇਖ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਇਸ ਲਈ ਇਹ ਪਰਚਾਰਕ ਲੱਗਦਾ ਹੈ।
ਫਾਉਂਡਰ ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਡੈਮੋ ਸਹੀ ਹੋਵੇ, ਇਸ ਲਈ ਉਹ ਚੈਟ 'ਚ ਐਡਮਿਨ ਪਹੁੰਚ ਦੇ ਦਿੰਦਾ ਹੈ। ਕੋਈ ਟਿਕਟ ਨਹੀਂ, ਕੋਈ ਲਿਖਤੀ ਪਰਿਧੀ ਨਹੀਂ, ਕੋਈ ਸਮਾਂ ਸੀਮਾ ਨਹੀਂ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਕਰਨ ਵਾਲੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਵਿਅਕਤੀ ਵਾਸਤਵ ਵਿੱਚ ਕੌਣ ਹੈ।
ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ, ਖਾਤਾ ਗਾਹਕ ਡੇਟਾ ਲੈਂਦਾ ਹੈ, ਨਵੀਂ API ਕੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਸਥਿਰਤਾ ਲਈ ਇੱਕ ਦੂਜਾ ਯੂਜ਼ਰ ਜੋੜਦਾ ਹੈ। ਜੇ ਕੁਝ ਬੁਰਾ ਹੋ ਜਾਵੇ, ਟੀਮ ਨਹੀਂ ਦੱਸ ਸਕਦੀ ਕਿ ਇਹ ਗਲਤੀ ਸੀ, ਇੱਕ ਜਲਦੀ ਕੀਤਾ ਬਦਲਾਅ ਸੀ, ਜਾਂ ਕੋਈ ਦੂਜਾ ਹਮਲਾ।
“ਐਡਮਿਨ” ਦੇਣ ਦੀ ਥਾਂ, ਸਭ ਤੋਂ ਛੋਟਾ ਰੋਲ ਦਿਓ ਜੋ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਹੈ, ਅਤੇ ਕੇਵਲ ਇਕ ਛੋਟੀ ਵਿੰਡੋ ਲਈ। ਇਕ ਸਧਾਰਨ ਨਿਯਮ: ਹਰੇਕ ਪਹੁੰਚ ਬਦਲਾਅ ਹਰ ਵਾਰ ਉਸੇ ਰਸਤੇ ਤੋਂ ਹੋਵੇ, ਭਾਵੇਂ ਤੁਸੀਂ ਤਣਾਓ 'ਚ ਹੋ।
ਅਮਲ ਵਿੱਚ:
ਆਡੀਟ ਟ੍ਰੇਲਾਂ ਨਾਲ, ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ: ਕਿਸਨੇ ਪਹੁੰਚ ਮਨਜ਼ੂਰ ਕੀਤੀ, ਕਦੋਂ ਸ਼ੁਰੂ ਹੋਈ, ਕੀ ਛੋਹਿਆ ਗਿਆ, ਅਤੇ ਕੀ ਨਵੀਆਂ ਕੀਆਂ ਜਾਂ ਯੂਜ਼ਰ ਬਣਾਏ ਗਏ। ਅਲਰਟ ਸਧਾਰਨ ਰੱਖੋ: ਟੀਮ ਨੂੰ ਸੂਚਿਤ ਕਰੋ ਜਦੋਂ ਇੱਕ privileged ਰੋਲ ਦਿੱਤਾ ਜਾਏ, ਜਦੋਂ credentials ਬਣਦੀਆਂ ਹਨ, ਜਾਂ ਜਦੋਂ ਪਹੁੰਚ ਨਵੀਂ ਜਗਾ/ਡਿਵਾਈਸ ਤੋਂ ਵਰਤੀ ਜਾਵੇ।
ਇਸ ਘਟਨਾ ਨੂੰ ਇੱਕ ਇਕ-ਸਫ਼ਾ ਅੰਦਰੂਨੀ ਪਲੇਬੁੱਕ ਵਿੱਚ ਲਿਖੋ: “Urgent access request.” ਸਪਸ਼ਟ ਕਦਮ, ਕੌਣ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਲੌਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਫਿਰ ਇਸ ਨੂੰ ਇੱਕ ਵਾਰ ਅਭਿਆਸ ਕਰੋ, ਤਾਂ ਜੋ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਵੀ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਬਣ ਜਾਵੇ।
Mitnick ਦੀ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਸਿਖਲਾਈ “ਸਮਝਦਾਰ ਕਰਮਚਾਰੀਆਂ” ਨਹੀਂ ਹੈ। ਇਹ ਹੈ ਰੋਜ਼ਾਨਾ ਕੰਮ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰੋ ਕਿ ਇੱਕ ਜਲਦੀ ਕੀਤਾ ਫੈਸਲਾ ਕੰਪਨੀ-ਵਿਆਪਕ ਸਮੱਸਿਆ ਵਿੱਚ ਨਾ ਬਦਲੇ।
ਸ਼ੁਰੂ ਕਰੋ ਉਹ ਲਹਿਰਾਂ ਨਾਮ ਦੇ ਕੇ ਜੋ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀਆਂ ਹਨ। ਉੱਚ-ਖਤਰੇ ਕਾਰਵਾਈਆਂ ਦੀ ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਲਿਖੋ, ਫਿਰ ਹਰ ਇੱਕ ਲਈ ਇੱਕ ਵਾਧੂ ਚੈੱਕ ਜੋੜੋ। ਇਹਨਾ ਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਲੋਕ ਅਸਾਨੀ ਨਾਲ ਫੋਲੋ ਕਰਨ।
ਦੋ ਦੌਰਾਨੀ ਸਮੀਖਿਆਆਂ ਚੁਣੋ ਅਤੇ ਉਨਾਂ ਨੂੰ ਕੈਲੇਂਡਰ 'ਤੇ ਰੱਖੋ। ਲਗਾਤਾਰਤਾ ਵੱਡੇ ਇੱਕ-ਵਾਰੀ ਸਫਾਈਆਂ ਤੋਂ ਵਧੀਆ ਹੈ।
ਮਹੀਨਵਾਰ ਪਹੁੰਚ ਸਮੀਖਿਆ ਕਰੋ: ਕਿਸ ਕੋਲ ਐਡਮਿਨ, ਬਿਲਿੰਗ, ਪ੍ਰੋਡਕਸ਼ਨ, ਅਤੇ ਡੇਟਾਬੇਸ ਪਹੁੰਚ ਹੈ? ਸਾਪਤਾਹਿਕ ਲੌਗ ਸਮੀਖਿਆ: ਨਵੇਂ ਐਡਮਿਨ, ਨਵੀਆਂ API ਕੁੰਜੀਆਂ, ਮੈਸ ਐਕਸਪੋਰਟ, ਅਤੇ ਫੇਲ੍ਹ ਲੌਗਇਨ ਸਪਾਈਕ ਨੂੰ ਸਕੈਨ ਕਰੋ। ਅਪਵਾਦਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ: ਕੋਈ ਵੀ ਅਸਥਾਈ ਪਹੁੰਚ ਇੱਕ ਮਿਆਦ-ਤਾਰੀਖ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਆਨਬੋਰਡਿੰਗ ਅਤੇ ਆਫ਼ਬੋਰਡਿੰਗ ਨੂੰ ਨਿਰਾਸ਼ਜਨਕ ਅਤੇ ਸੰਖੇਪ ਬਣਾਓ। ਇੱਕ ਛੋਟੀ-ਚੈਕਲਿਸਟ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਮਾਲਕ ਉਦਾਹਰਨੀ ਰੋਕਦੇ ਹਨ: ਪੁਰਾਣੇ ਠੇਕੇਦਾਰ, ਇੰਟਰਨ, ਅਤੇ ਭੁੱਲੇ ਹੋਏ ਸਰਵਿਸ ਖਾਤੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਵੀ ਪਹੁੰਚ ਰੱਖਣ ਦੀ ਸਮੱਸਿਆ।
ਜਦੋਂ ਤੁਸੀਂ ਐਸਾ ਟੂਲ ਸ਼ਿਪ ਕਰਦੇ ਹੋ ਜੋ ਗਾਹਕ ਡੇਟਾ ਜਾਂ ਪੈਸਾ ਛੁਹਦਾ ਹੈ, ਡਿਫਾਲਟ ਸੈਟਅਪ ਸੁਰੱਖਿਆ ਦਸਤਾਵੇਜ਼ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਪੱਸ਼ਟ ਰੋਲਾਂ ਦਾ ਲਕੜੀ ਪ੍ਰਯੋਗ ਕਰੋ: ਇੱਕ viewer ਰੋਲ ਜੋ ਐਕਸਪੋਰਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇੱਕ editor ਰੋਲ ਜੋ ਅਨੁਮਤੀਆਂ ਨਹੀਂ ਬਦਲ ਸਕਦਾ, ਅਤੇ admin ਸਿਰਫ ਜਦੋਂ ਬਚਾ ਰਹੋ।
ਜੋ ਡਿਫਾਲਟ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਐਪ ਬਣਾਉਂਦੇ ਅਤੇ ਡਿਪਲੋਇ ਕਰਦੇ ਹੋ, ਉਥੇ ਵੀ ਉਹੀ ਸੋਚ ਲਗਾਓ: ਐਡਮਿਨ ਪਹੁੰਚ ਕਸੋ, ਡਿਪਲੋਇਜ਼ ਅਤੇ ਐਕਸਪੋਰਟ ਲੌਗ ਕਰੋ, ਅਤੇ ਜਲਦੀ ਕੀਤੇ ਗਲਤ ਬਦਲਾਅ ਨੂੰ ਵਾਪਸ ਲਿਆਉਣ ਲਈ snapshots/rollback ਤੇ ਭਰੋਸਾ ਕਰੋ।
ਇੱਕ ਆਸਾਨ ਨਿਯਮ ਨਾਲ ਖਤਮ ਕਰੀਏ: ਜੇ ਕੋਈ ਬਿਨਤੀ ਤੁਰੰਤ ਹੈ ਅਤੇ ਪਹੁੰਚ ਦਬਲਦੀ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਦੂਜੇ ਚੈਨਲ ਰਾਹੀਂ ਪੁਸ਼ਟੀ ਕਰੋ।
ਅਧਿਕਤਮ ਬ੍ਰੀਚ ਇੱਕ ਛੋਟੀ, ਆਮ ਕਾਰਵਾਈਆਂ ਦੀ ਸੀਰੀਜ਼ ਹੁੰਦੀ ਹੈ:
ਇਸ ਲਈ ਜੋ “ਗਲਤੀ” ਦਿਖਦੀ ਹੈ, ਉਹ ਅਕਸਰ ਕਮਜ਼ੋਰ ਵਰਕਫਲੋ ਵਿੱਚ ਆਖਰੀ ਦਿੱਖਣ ਯੋਗ ਕਦਮ ਹੀ ਹੁੰਦੀ ਹੈ।
ਸੋਸ਼ਲ ਇੰਜੀਨੀਅਰਿੰਗ ਉਹ ਹੈ ਜਦੋਂ ਹਮਲਾਵਰ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਇਹ ਰਜ਼਼ਾਮੰਦੀ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਹਮਲਾਵਰ ਦੀ ਮਦਦ ਕਰੇ — ਜਿਵੇਂ ਕੋਈ ਕੋਡ ਸਾਂਝਾ ਕਰਨਾ, ਪਹੁੰਚ ਮਨਜ਼ੂਰ ਕਰਨਾ, ਜਾਂ ਜ਼ਾਲੀ ਲੌਗਿਨ ਪੇਜ਼ 'ਤੇ ਲੌਗ ਇਨ ਕਰਵਾਉਣਾ।
ਇਹ ਇਸ ਵੇਲੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਬਿਨਤੀ ਸਧਾਰਨ, ਤੁਰੰਤ ਅਤੇ ਆਸਾਨ ਲੱਗਦੀ ਹੈ।
ਇਕ ਸਧਾਰਨ ਨਿਯਮ ਵਰਤੋ: ਕੋਈ ਵੀ ਬਿਨਤੀ ਜੋ ਪਹੁੰਚ ਬਦਲਦੀ ਹੈ ਜਾਂ ਪੈਸਾ ਘੁਮਾਉਂਦੀ ਹੈ, ਦੂਜੇ ਚੈਨਲ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਵਿਅਵਹਾਰਕ ਉਦਾਹਰਨ:
ਬਿਨਤੀ ਵਿਚ ਦਿੱਤੇ ਫ਼ੋਨ ਨੰਬਰ ਜਾਂ ਈਮੇਲ 상세 ਤੁਹਾਡੇ ਦੁਆਰਾ ਉਹੀ ਨਹੀਂ ਵਰਤਣੇ।
3–5 ਰੋਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋਨ (ਉਦਾਹਰਨ: Admin, Engineer, Support, Finance, Contractor).
ਮਗਰ ਦੋ ਮੌਲਿਕ ਨਿਯਮ ਲਗਾਓ:
ਇਸ ਨਾਲ ਟੀਮ ਦੀ ਤੇਜ਼ੀ ਬਣੀ ਰਹਿੰਦੀ ਹੈ ਪਰ ਖਤਰਾ ਘਟਦਾ ਹੈ।
ਆਫ਼ਬੋਰਡਿੰਗ ਨੂੰ ਇਕੋ ਦਿਨ ਦਾ ਕੰਮ ਸਮਝੋ, ਬੈਕਲੌਗ ਬਾਡੇ ਆਈਟਮ ਵਾਂਗ ਨਾ ਛੱਡੋ.
ਘੱਟੋ-ਘੱਟ ਚੈੱਕਲਿਸਟ:
ਆਫ਼ਬੋਰਡਿੰਗ ਫੇਲਿਯਰ ਆਮ ਹਨ ਕਿਉਂਕਿ ਪੁਰਾਣੀ ਪਹੁੰਚ ਸ਼ਾਂਤ ਰੂਪ ਨਾਲ ਵਜੂਦ ਵਿੱਚ ਰਹਿ ਜਾਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਲਾਗ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਉਹ ਘੱਟ-ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਘਟਨਾਵਾਂ ਲਾਗ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ:
ਲੌਗਾਂ ਨੂੰ ਛੋਟੀ-ਸੀ ਟੀਮ ਵਰਤ ਸਕੇ — ਇੱਕ ਨਿਰਧਾਰਿਤ ਮਾਲਕ ਹੋਣਾ ਜਰੂਰੀ ਹੈ ਜੋ ਉਹਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੇ।
ਸ਼ਾਂਤ ਪਰ ਉੱਚ-ਸੰਕੇਤ ਵਾਲੇ ਅਲਰਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ. ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸੈਟ:
ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਲਰਟ ਲੋਕਾਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਾਉਂਦੇ ਹਨ; ਕੁਝ ਤੇਜ਼ਅਸਰ ਅਲਰਟ ਕਾਰਗਰ ਹੁੰਦੇ ਹਨ।
ਕੌਨਟ੍ਰੈਕਟਰਾਂ ਨੂੰ ਅਲੱਗ ਰੋਲ ਦਿਓ ਜਿਸਦੀ ਸਪਸ਼ਟ ਸੀਮਾ ਅਤੇ ਖਤਮ ਹੋਣ ਦੀ ਤਾਰੀਖ ਹੋਵੇ.
ਛੰਗਾ ਆਧਾਰ:
ਜੇ ਓਹਨਾਂ ਨੂੰ ਵੱਧ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਅਰਥਕਾਲਿਕ ਤੌਰ 'ਤੇ ਵੇਖੋ ਅਤੇ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਰਿਕਾਰਡ ਕਰੋ।
’Safer defaults’ ਉਹ ਸ਼ੁਰੂਆਤੀ ਸੈਟਿੰਗ ਹਨ ਜੋ ਗਲਤ ਫੈਸਲੇ ਜਾਂ ਭੁੱਲ ਤੋਂ ਨੁਕਸਾਨ ਘਟਾਉਂਦੀਆਂ ਹਨ:
ਐਸੇ Defaults ਲੋਕਾਂ ਨੂੰ ਦਬਾਅ ਵਾਲੇ ਸਮਿਆਂ 'ਚ ਓਹਨਾਂ ਨੂੰ ਚੋਰਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
ਇੱਕ ਵਿਹੰਗਮ 30 ਦਿਨ ਦੀ ਯੋਜਨਾ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਂਦੇ ਅਤੇ ਡਿਪਲੋਇ ਕਰਦੇ ਹੋ (ਜਿਸ ਵਿੱਚ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਵੀ ਸ਼ਾਮਲ ਹਨ), ਤਾਂ ਏਕਸਪੋਰਟ, ਡਿਪਲੋਇਮੈਂਟ, ਅਤੇ ਕਸਟਮ ਡੋਮੇਨ ਬਣਾ-ਭੈਣ ਕਾਰਵਾਈਆਂ ਵਜੋਂ ਸੋਚੋ।