20 ਅਕਤੂ 2025·8 ਮਿੰਟ
Jay Chaudhry Zscaler: ਕਲਾਉਡ ਪੈਮਾਨੇ ਲਈ ਬਣਿਆ ਜ਼ੀਰੋ-ਟਰੱਸਟ
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਜ਼ਰੀਆ ਕਿ Jay Chaudhry ਅਤੇ Zscaler ਨੇ ਕਿਵੇਂ ਕਲਾਉਡ ਸੁਰੱਖਿਆ, ਜ਼ੀਰੋ-ਟਰੱਸਟ ਅਤੇ ਸਾਥੀਆਂ ਦੀ ਵੰਡ ਰਣਨੀਤੀ ਨਾਲ ਇੱਕ ਆਗੂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਕੰਪਨੀ ਬਣਾਈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਜ਼ਰੀਆ ਕਿ Jay Chaudhry ਅਤੇ Zscaler ਨੇ ਕਿਵੇਂ ਕਲਾਉਡ ਸੁਰੱਖਿਆ, ਜ਼ੀਰੋ-ਟਰੱਸਟ ਅਤੇ ਸਾਥੀਆਂ ਦੀ ਵੰਡ ਰਣਨੀਤੀ ਨਾਲ ਇੱਕ ਆਗੂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਕੰਪਨੀ ਬਣਾਈ।
ਇਹ Jay Chaudhry ਦੀ ਜੀਵਨੀ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਕਹਾਣੀ ਹੈ ਕਿ Zscaler ਨੇ ਕਿਵੇਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਨੂੰ ਸੁਧਾਰਿਆ—ਅਤੇ ਕਿਉਂ ਉਸਦੇ ਫੈਸਲੇ (ਟੈਕਨੀਕੀ ਅਤੇ ਵਪਾਰੀ ਦੋਹਾਂ) ਮਾਣਕ ਰੱਖਦੇ ਸਨ।
ਤੁਸੀਂ ਇਕੱਠੇ ਦੋ ਗੱਲਾਂ ਸਿੱਖੋਗੇ:
ਆਧੁਨਿਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਉਹ ਨਿਯੰਤਰਣਾਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਇੰਟਰਨੈੱਟ ਅਤੇ ਅੰਦਰੂਨੀ ਐਪਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਬਿਨਾਂ ਇਸ ਧਾਰਨਾ ਦੇ ਕਿ ਕੁਝ ਵੀ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿਉਂਕਿ ਉਹ “ਕੋਈ ਕੰਪਨੀ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ” ਹੈ। ਇਹ ਵੱਡੀ ਭਿੰਡ ਬਣਾਉਣ ਬਜਾਏ ਇਹ ਦੇਖਣ 'ਤੇ ਜ਼ਿਆਦਾ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਕਿ ਕੌਣ ਜੁੜ ਰਿਹਾ ਹੈ, ਕੀ ਜੁੜ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਿਆ ਉਸ ਸੰਬੰਧ ਨੂੰ ਮਨਜ਼ੂਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਹਰ ਵਾਰੀ।
ਅਖੀਰ ਤਕ, ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿਚ Zscaler ਦੀ ਮੂਲ ਦਾਵੇਦਾਰੀ ਸਮਝਾ ਸਕੋਗੇ, ਵੇਖ ਸਕੋਗੇ ਕਿ ਜਿੱਥੇ ਜ਼ੀਰੋ-ਟਰੱਸਟ VPN ਯੁੱਗ ਦੀ ਸੋਚ ਨੂੰ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਸਮਝ ਸਕੋਗੇ ਕਿ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਰਣਨੀਤੀ ਕਿਵੇਂ ਉਤਨੇ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੀ ਹੈ ਜਿੰਨੀ ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ।
Jay Chaudhry ਇੱਕ ਸੀਰੀਅਲ ਉਦਯਮੀ ਹਨ, ਜੋ Zscaler ਦੇ ਫਾਉਂਡਰ ਅਤੇ CEO ਵਜੋਂ ਸਭ ਤੋਂ ਵੱਧ ਮੰਨੇ ਜਾਂਦੇ ਹਨ—ਉਸ ਕੰਪਨੀ ਨੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਨੂੰ “ਕੰਪਨੀ ਨੈੱਟਵਰਕ ਦੀ ਰੱਖਿਆ” ਤੋਂ “ਜਿੱਥੇ ਵੀ ਯੂਜ਼ਰ ਅਤੇ ਐਪ ਹਨ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ” ਵੱਲ ਮੋੜਿਆ। Zscaler ਤੋਂ ਪਹਿਲਾਂ, ਉਸਨੇ ਕਈ ਸੁਰੱਖਿਆ ਸਟਾਰਟਅਪ ਬਣਾਏ ਅਤੇ ਵੇਚੇ, ਜਿਸ ਨਾਲ ਉਸਨੂੰ ਹਮਲਾ ਕਰਨ ਵਾਲਿਆਂ ਦੇ ਰਵੱਈਏ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ IT ਦੇ ਤੇਜ਼ ਬਦਲਾਅ ਦਾ ਪਹਿਲਾ ਦਰਜਾ ਤਜ਼ਰਬਾ ਮਿਲਿਆ।
Chaudhry ਦਾ ਧਿਆਨ ਸਾਫ਼ ਸੀ: ਜਿਵੇਂ-ਜਿਵੇਂ ਕੰਮ ਅਤੇ ਐਪਸ ਕੰਪਨੀ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ ਜਾਂ ਸਾਰਵਜਨਿਕ ਇੰਟਰਨੈੱਟ ਅਤੇ ਕਲਾਉਡ ਸਰਵਿਸਿਜ਼ ਵੱਲ ਗਏ, ਪੁਰਾਣਾ ਮਾਡਲ ਜਿਸ ਵਿੱਚ ਸਭ ਕੁਝ ਕੇਂਦਰੀ ਡੇਟਾ ਸੈਂਟਰ ਰਾਹੀਂ ਰਾਊਟ ਕਰਕੇ ਇੰਸਪੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਸੀ ਉਹ ਟੁੱਟਣ ਲੱਗਾ।
ਇਹ ਬਦਲਾਅ IT ਟੀਮਾਂ ਲਈ ਇੱਕ ਦਰਦਨਾਕ ਟਰੇਡ-ਆਫ਼ ਪੈਦਾ ਕਰਦਾ ਸੀ:
Zscaler ਦੀ ਮੁਢਲੀ ਧਾਰਨਾ ਸੀ ਕਿ ਸੁਰੱਖਿਆ ਨੂੰ ਇਮਾਰਤ ਦੇ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਯੂਜ਼ਰ ਦੇ ਨਾਲ ਚਲਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੋ ਚੀਜ਼ ਪ੍ਰਤੱਖ ਹੈ ਉਹ ਇਹ ਕਿ ਫਾਉਂਡਰ-ਅਧੀਨ ਉਤਪਾਦ ਦ੍ਰਿਸ਼ਟੀ ਨੇ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਕੰਪਨੀ ਦੀ ਰਣਨੀਤੀ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ:
ਇਹ ਸਿਰਫ਼ ਮਾਰਕੀਟਿੰਗ ਨੁੰਹ ਨਹੀਂ ਸੀ; ਇਹ ਉਤਪਾਦ ਫੈਸਲੇ, ਸਾਥੀ ਚੋਣਾਂ, ਅਤੇ ਜਦੋਂ Zscaler ਨੇ ਮਹਿਫੂਜ਼-ਰੁਝੇ ਅਣਵਲ buyers ਨੂੰ “ਕਿਉਂ” ਸਮਝਾਇਆ, ਤਾੰមាន ਇਹ ਸਪੱਸ਼ਟਤਾ ਬਜਟ ਲਾਈਨਾਂ ਵਿਚ ਬਦਲੀ—ਉਹ ਕੁਝ ਜੋ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਖਰੀਦ ਸਕਦੀਆਂ, ਤੈਨਾਤ ਕਰ ਸਕਦੀਆਂ, ਅਤੇ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰ ਸਕਦੀਆਂ।
ਕਈ ਸਾਲਾਂ ਲਈ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ 'ਤੇ ਟਿਕੀ ਸੀ: “ਵਧੀਆ ਚੀਜ਼ਾਂ” ਨੂੰ ਕੰਪਨੀ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਰੱਖੋ, ਅਤੇ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਦੀਵਾਰ ਬਣਾਓ। ਉਹ ਦੀਵਾਰ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਆਨ-ਪ੍ਰੇਮ ਡਿਵਾਈਸ—ਫਾਇਰਵਾਲ, ਵੈੱਬ ਪ੍ਰਾਕਸੀ, ਇੰਟ੍ਰੂਜੇਨ ਪ੍ਰੀਵੈਂਸ਼ਨ—ਇੱਕ ਜਾਂ ਦੋ ਡੇਟਾ ਸੈਂਟਰਾਂ 'ਚ ਰੱਖਕੇ ਬਣਾਈ ਜਾਂਦੀ ਸੀ। ਰਿਮੋਟ ਕਰਮਚਾਰੀ VPN ਰਾਹੀਂ ਜੁੜਦੇ ਜੋ ਅਸਲ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਤੱਕ ਫੈਲਾਉਂਦਾ ਸੀ।
ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਐਪਸ ਕੰਪਨੀ ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਸਨ, ਇਹ ਠੀਕ ਕੰਮ ਕਰਦਾ ਸੀ। ਵੈੱਬ ਅਤੇ ਐਪ ਟ੍ਰੈਫਿਕ ਇੱਕੋ ਜਿਹੇ ਚੌਕ-ਪਾਇੰਟਾਂ ਰਾਹੀਂ ਵਹਿਦੇ, ਜਿਥੇ ਸੁਰੱਖਿਆ ਟੀਮ ਇੰਸਪੈਕਟ, ਲੌਗ ਅਤੇ ਰੋਕ ਸਕਦੀ ਸੀ।
ਪਰ ਇਹ ਮਾਡਲ ਦੋ ਧਾਰਨਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ ਜੋ ਹੁਣ ਸਹੀ ਨਹੀਂ ਰਹਿੰਦੀਆਂ:
ਜਿਵੇਂ-ਜਿਵੇਂ ਕਰਮਚਾਰੀ ਮੋਬਾਈਲ ਹੋਏ ਅਤੇ SaaS ਦੀ ਵਰਤੋਂ ਤੇਜ਼ ਹੋਈ, ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ ਬਦਲ ਗਏ। ਕੌਫੀ-ਸ਼ਾਪਾਂ ਵਿੱਚ ਬੈਠੇ ਲੋਕਾਂ ਨੂੰ Office 365, Salesforce ਅਤੇ ਦਹਾੜੀਆਂ ਬ੍ਰਾਊਜ਼ਰ-ਅਧਾਰਿਤ ਟੂਲਾਂ ਲਈ ਤੇਜ਼ ਐਕਸਸ ਦੀ ਲੋੜ ਸੀ—ਅਕਸਰ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਪੋਰੇਟ ਡੇਟਾ ਸੈਂਟਰ ਨੂੰ ਛੂਹੇ।
ਨੀਤੀ ਲਾਗੂ ਰੱਖਣ ਲਈ, ਕਈ ਕੰਪਨੀਆਂ ਨੇ ਟ੍ਰੈਫਿਕ ਨੂੰ “ਬੈਕਹੌਲ” ਕੀਤਾ: ਯੂਜ਼ਰ ਦੇ ਇੰਟਰਨੈੱਟ ਅਤੇ SaaS ਬੇਨਤੀਆਂ ਨੂੰ ਪਹਿਲਾਂ HQ ਰਾਹੀਂ ਭੇਜੋ, ਇੰਸਪੈਕਟ ਕਰੋ, ਫਿਰ ਵਾਪਸ ਬੇਜੋ। ਨਤੀਜਾ ਪੇਸ਼ਗੋਈਯੋਗ ਸੀ: ਧੀਮੀ ਪ੍ਰਦਰਸ਼ਨ, ਨੀਰਾਸ ਯੂਜ਼ਰ, ਅਤੇ ਨਿਯੰਤ੍ਰਣਾਂ ਵਿੱਚ ਛਿਦਰ ਬਣਾਉਣ ਦਾ ਦਬਾਅ।
ਜਟਿਲਤਾ ਵੱਧ ਗਈ (ਜ਼ਿਆਦਾ ਡਿਵਾਈਸ, ਜ਼ਿਆਦਾ ਨੀਤੀਆਂ, ਜ਼ਿਆਦਾ ਛੂਟ)। VPN ਓਵਰਲੋਡ ਅਤੇ ਖਤਰਨਾਕ ਹੋ ਗਏ ਜਦੋਂ ਉਹ ਵਿਆਪਕ ਨੈੱਟਵਰਕ ਐਕਸਸ ਦਿੰਦੇ। ਹਰ ਨਵੀਂ ਸ਼ਾਖਾ ਜਾਂ ਅਧਿਗ੍ਰਹਣ ਦਾ ਮਤਲਬ ਹੋਰ ਹਾਰਡਵੇਅਰ ਰੋਲਆਉਟ, ਹੋਰ ਸਮਰੱਥਾ ਯੋਜਨਾ, ਅਤੇ ਹੋਰ ਕੋਮਲ ਬਣੀ ਆਰਕੀਟੈਕਚਰ ਸੀ।
ਇਹ ਫਾਅਰ—ਕੋਨਸਿਸਟੈਂਟ ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ ਬਿਨਾਂ ਇਹ ਮਜ਼ਬੂਤ ਪਰਿਮੀਟਰ ਹੋਣ ਦੇ—ਕਲਾਉਡ-ਡਿਲਿਵਰ ਕੀਤੀ ਸੁਰੱਖਿਆ ਲਈ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹਿਆ ਜੋ ਯੂਜ਼ਰ ਅਤੇ ਐਪ ਨਾਲ ਚੱਲ ਸਕਦੀ ਸੀ, ਨਾ ਕਿ ਇਮਾਰਤ ਦੇ ਨਾਲ।
Zscaler ਦਾ ਪਰਿਭਾਸ਼ਕ ਦਾਵਾ ਆਸਾਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸੀ ਪਰ ਅਮਲ ਵਿੱਚ ਮੁਸ਼ਕਲ: ਸੁਰੱਖਿਆ ਨੂੰ ਬਕਸਿਆਂ ਵਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਕਲਾਉਡ ਸੇਵਾ ਵਜੋਂ ਡਿਲਿਵਰ ਕਰੋ, ਜੋ ਯੂਜ਼ਰਾਂ ਦੇ ਨੇੜੇ ਪੋਜ਼ੀਸ਼ਨ ਕੀਤੀ ਗਈ ਹੋਵੇ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਕਲਾਉਡ ਸੁਰੱਖਿਆ” ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਕਲਾਉਡ ਸਰਵਰਾਂ ਦੀ ਰੱਖਿਆ ਨਹੀਂ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਖੁਦ ਸੁਰੱਖਿਆ ਕਲਾਉਡ ਵਿੱਚ ਚਲਦੀ ਹੈ—ਤਾਂ ਜੋ ਇੱਕ ਬ੍ਰਾਂਚ, ਘਰ ਜਾਂ ਮੋਬਾਇਲ 'ਤੇ ਯੂਜ਼ਰ ਨੇੜਲੇ PoP ਨਾਲ ਜੁੜੇ ਅਤੇ ਉੱਥੇ ਨੀਤੀ ਲਾਗੂ ਕੀਤੀ ਜਾਵੇ।
"ਇਨਲਾਈਨ" ਹੀ ਇਸਨੂੰ ਇੱਕ ਸੁਰੱਖਿਆ ਚੈੱਕਪੋਇੰਟ ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਰੂਟ ਕਰਨ ਵਰਗਾ ਹੈ ਜੋ ਮਨਜ਼ਿਲ ਵੱਲ ਜਾ ਰਹੇ ਰਸਤੇ 'ਤੇ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਕਰਮਚਾਰੀ ਕਿਸੇ ਵੈੱਬਸਾਈਟ ਜਾਂ ਕਲਾਉਡ ਐਪ ਨੂੰ ਜਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਉਸਦੀ ਕਨੈਕਸ਼ਨ ਸੇਵਾ ਰਾਹੀਂ ਸਟੀਅਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸੇਵਾ ਜਿੰਨਾ ਸਕੇ ਤਦ ਇੰਸਪੈਕਟ ਕਰਦੀ ਹੈ (ਨੀਤੀ ਦੇ ਅਧਾਰ 'ਤੇ), ਖਤਰਨਾਕ ਗੰਢੀਆਂ ਨੂੰ ਰੋਕਦੀ ਹੈ, ਧਮਕੀਆਂ ਲਈ ਸਕੈਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਮਨਜ਼ੂਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅੱਗੇ ਭੇਜਦੀ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਾਰਪੋਰੇਟ-ਗਰੇਡ ਸੁਰੱਖਿਆ ਮਿਲੇ ਬਿਨਾਂ ਇਹ ਲੋੜ ਹੋਏ ਕਿ ਉਹ “ਕੰਪਨੀ ਨੈੱਟਵਰਕ” 'ਤੇ ਹੋਣ। ਸੁਰੱਖਿਆ ਯੂਜ਼ਰ ਦੇ ਨਾਲ-ਨਾਲ ਚੱਲਦੀ ਹੈ।
ਕਲਾਉਡ-ਡਿਲਿਵਰ ਕੀਤੀ ਸੁਰੱਖਿਆ IT ਅਤੇ ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਦੀ ਦੈਨਿਕ ਹਕੀਕਤ ਬਦਲ ਦਿੰਦੀ ਹੈ:
ਇਹ ਮਾਡਲ ਇਸ ਗੱਲ ਨਾਲ ਵੀ ਮੇਲ ਖਾਂਦਾ ਹੈ ਕਿ ਕੰਪਨੀਆਂ ਅਸਲ ਵਿੱਚ ਹੁਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਟ੍ਰੈਫਿਕ ਬਹੁਤ ਵਾਰ ਸਿੱਧਾ SaaS ਅਤੇ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਵੱਲ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਪਹਿਲਾਂ ਹੀ “ਹੈੱਡਕੁਆਰਟਰ” ਵੱਲ।
ਤੀਜੀ ਪਾਰਟੀ ਨੂੰ ਇਨਲਾਈਨ ਰੱਖਣਾ ਹਕੀਕਤੀ ਚਿੰਤਾਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਮੁੱਲਿਆੰਕਣ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ:
ਮੁੱਖ ਦਾਵਾ ਇਸ ਲਈ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਨਹੀਂ—ਇਹ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਭਰੋਸਾ ਹੈ ਕਿ ਇੱਕ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਨੀਤੀ ਭਰੋਸੇਯੋਗ, ਪਾਰਦਰਸ਼ੀ, ਅਤੇ ਗਲੋਬਲ ਪੈਮਾਨੇ 'ਤੇ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ।
ਜ਼ੀਰੋ-ਟਰੱਸਟ ਇੱਕ ਸਧਾਰਨ ਸਿਧਾਂਤ ਹੈ: ਕਦੇ ਵੀ ਇਹ ਧਾਰਨਾ ਨਾ ਕਰੋ ਕਿ ਕੁਛ ਸੁਰੱਖਿਅਤ ਹੈ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਉਹ "ਕੰਪਨੀ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ" ਹੈ। ਇਸ ਦੀ ਥਾਂ, ਹਮੇਸ਼ਾ ਤਸਦੀਕ ਕਰੋ ਕਿ ਯੂਜ਼ਰ ਕੌਣ ਹੈ, ਉਹ ਕਿਸ ਡਿਵਾਈਸ 'ਤੇ ਹੈ, ਅਤੇ ਉਹ ਕਿਸ ਖਾਸ ਐਪ ਜਾਂ ਡਾਟਾ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਅਨੁਮਤੀ ਰੱਖਦਾ ਹੈ—ਹਰ ਵਾਰੀ ਜਦੋਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ।
ਰਵਾਇਤੀ VPN ਸੋਚ ਇਹ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਅੰਦਰ ਆਉਣ 'ਤੇ ਕਿਸੇ ਨੂੰ ਇੱਕ ਬੈਜ ਦਿੱਤਾ ਜਾਵੇ ਜੋ ਸਾਰੇ ਦਰਵਾਜੇ ਖੋਲ੍ਹ ਦੇਵੇ। VPN ਜੁੜਨ ਤੋਂ ਬਾਅਦ, ਕਈ ਸਿਸਟਮ ਉਸ ਯੂਜ਼ਰ ਨੂੰ "ਅੰਦਰੂਨੀ" ਮੰਨ ਲੈਂਦੇ ਹਨ, ਜੋ ਉਮੀਦ ਤੋਂ ਵੱਧ ਖ਼ਤਰਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਜ਼ੀਰੋ-ਟਰੱਸਟ ਇਸ ਮਾਡਲ ਨੂੰ ਉਲਟਦਾ ਹੈ। ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ ਕਿਸੇ ਨੂੰ ਇੱਕ ਕੰਮ ਲਈ ਇੱਕ ਹੀ ਕਮਰਾ ਦਿੰਦਿਆਂ—ਤੁਸੀਂ ਚੌੜੇ ਤੌਰ 'ਤੇ ਨੈੱਟਵਰਕ ਨਾਲ ਨਹੀਂ ਜੁੜਦੇ; ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਉਹ ਐਪ ਮਿਲਦੀ ਹੈ ਜਿਹੜੀ ਤੁਹਾਡੇ ਲਈ ਮਨਜ਼ੂਰ ਹੋਈ ਹੈ।
ਇੱਕ ठੇਕੇਦਾਰ ਨੂੰ ਦੋ ਮਹੀਨੇ ਲਈ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਮੈਂਟ ਟੂਲ ਦੀ ਲੋੜ ਹੈ। ਜ਼ੀਰੋ-ਟਰੱਸਟ ਨਾਲ ਉਹ ਸਿਰਫ਼ ਉਸ ਇੱਕ ਐਪ ਤੱਕ ਐਕਸਸ ਪਾ ਸਕਦਾ ਹੈ—ਬਿਨਾਂ ਗਲਤੀ ਨਾਲ ਪੇਰੋਲ ਸਿਸਟਮ ਜਾਂ ਅੰਦਰੂਨੀ ਐਡਮਿਨ ਟੂਲਾਂ ਤੱਕ ਰਸਤਾ ਬਣਾਉਣ ਦੇ।
ਇੱਕ ਕਰਮਚਾਰੀ ਯਾਤਰਾ ਦੌਰਾਨ ਆਪਣੇ ਨਿੱਜੀ ਲੈਪਟਾਪ (BYOD) ਤੋਂ ਲੱਗ-ਭਗ ਜੇ ਵਰਤ ਰਿਹਾ ਹੈ। ਜ਼ੀਰੋ-ਟਰੱਸਟ ਨੀਤੀਆਂ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਲੌਗਇਨ ਜਾਂਚਾਂ ਮੰਗ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਜੇ ਡਿਵਾਈਸ ਪੁਰਾਣਾ, ਅਨਇਨਕ੍ਰਿਪਟਿਡ, ਜਾਂ ਸੰਕਟ ਦੇ ਨਿਸ਼ਾਨ ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਐਕਸਸ ਰੋਕ ਸਕਦੀਆਂ ਹਨ।
ਰਿਮੋਟ ਵਰਕ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ ਫੈਸਲਾ ਯੂਜ਼ਰ ਅਤੇ ਐਪ ਦੇ ਨਾਲ-ਨਾਲ ਅਨੁਸਰਣ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਸੇ ਭੌਤਿਕ ਦਫਤਰ ਨੈੱਟਵਰਕ ਦੇ ਨਾਲ।
ਜ਼ੀਰੋ-ਟਰੱਸਟ ਕੋਈ ਇਕ ਉਤਪਾਦ नहीं ਹੈ ਜੋ ਤੁਸੀਂ ਖਰੀਦ ਕੇ "ਚਾਲੂ" ਕਰ ਦਿੰਦੇ। ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਰਵੱਈਆ ਹੈ ਜੋ ਟੂਲਾਂ ਅਤੇ ਨੀਤੀਆਂ ਰਾਹੀਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇਹ ਇਹ ਵੀ ਨਹੀਂ ਕਿ "ਕਿਸੇ 'ਤੇ ਵੀ ਭਰੋਸਾ ਨਾ ਕਰੋ"। ਅਮਲ ਵਿੱਚ, ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਭਰੋਸਾ ਲਗਾਤਾਰ ਕਮਾਇਆ ਜਾਂਦਾ ਹੈ—ਪਹਿਚਾਣ ਜਾਂਚਾਂ, ਡਿਵਾਈਸ ਪੋਸਚਰ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਦੇ ਜ਼ਰੀਏ—ਤਾਂ ਜੋ ਗਲਤੀਆਂ ਅਤੇ ਘੁਸਪੈਠ ਫੈਲਣ ਤੇ ਰੁਕ ਸਕਣ।
Zscaler ਨੂੰ ਸਮਝਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਕਲਾਉਡ “ਕੰਟਰੋਲ ਪਾਇੰਟ” ਵਜੋਂ ਦੇਖਦੇ ਹੋ ਜੋ ਲੋਕਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਮਨਜ਼ਿਲਾਂ ਦੇ ਵਿਚਕਾਰ ਬੈਠਾ ਹੁੰਦਾ ਹੈ। ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ਬਾਊਂਡਰੀ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ, ਇਹ ਹਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਇਸ ਦੇ ਅਧਾਰ 'ਤੇ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਕੌਣ ਹੈ ਅਤੇ ਸਥਿਤੀ ਕੀ ਦਿੱਸਦੀ ਹੈ, ਫਿਰ ਠੀਕ ਨੀਤੀ ਲਗਾਉਂਦਾ ਹੈ।
ਅਧਿਕਤਮ ਡਿਪਲੋਯਮੈਂਟ ਚਾਰ ਸਧਾਰਨ ਟੁਕੜਿਆਂ ਨਾਲ ਵਰਣਨ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ:
ਧਾਰਨਾਤਮਕ ਤੌਰ 'ਤੇ, Zscaler ਟ੍ਰੈਫਿਕ ਨੂੰ ਦੋ ਲੇਨਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ:
ਇਹ ਵੰਡ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇੱਕ ਲੇਨ ਸੁਰੱਖਿਅਤ ਇੰਟਰਨੈੱਟ ਵਰਤੋਂ ਦੀ ਗੱਲ ਕਰਦੀ ਹੈ; ਦੂਜੀ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਨਿਰਧਾਰਿਤ ਪਹੁੰਚ।
ਫੈਸਲੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਦਫਤਰ IP ਐਡ੍ਰੈੱਸ 'ਤੇ ਆਧਾਰਿਤ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਸੂਚਕਾਂ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੇ ਹਨ ਜਿਵੇਂ ਯੂਜ਼ਰ ਕੌਣ ਹੈ, ਡਿਵਾਈਸ ਦੀ ਸਿਹਤ (ਪ੍ਰਬੰਧਿਤ vs ਅਨ-ਪ੍ਰਬੰਧਿਤ, ਪੈਚ ਕੀਤਾ vs ਪੁਰਾਣਾ), ਅਤੇ ਕਿੱਥੇ/ਕਿਵੇਂ ਜੁੜ ਰਹੇ ਹਨ।
ਚੰਗੇ ਢੰਗ ਨਾਲ ਕੀਤਾ ਗਿਆ, ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਘਟਾਉਂਦਾ ਹੈ, ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਲੈਟਰਲ ਮੂਵਮੈਂਟ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਐਕਸਸ ਕੰਟਰੋਲ ਨੂੰ ਇੱਕ ਸਰਲ, ਇਕਸਾਰ ਨੀਤੀ ਮਾਡਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਰਿਮੋਟ ਵਰਕ ਅਤੇ ਕਲਾਉਡ-ਫਰਸਟ ਐਪ ਸਟੈਕ ਡਿਫੌਲਟ ਬਣ ਜਾਣ।
ਜਦੋਂ ਲੋਕ “ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ” ਬਾਰੇ ਸੋਚਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਅੰਦਰੂਨੀ ਐਪਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਦੀਆਂ ਚੀਜ਼ਾਂ ਸੋਚਦੇ ਹਨ। ਪਰ ਜੋਖਮ ਦਾ ਇੱਕ ਵੱਡਾ ਹਿੱਸਾ ਖੁੱਲ੍ਹੇ ਇੰਟਰਨੈੱਟ ਪਾਸੇ ਬੈਠਾ ਹੈ: ਕਰਮਚਾਰੀ ਖ਼ਬਰਾਂ-ਸਾਈਟਾਂ ਬਰਾਊਜ਼ ਕਰਦੇ, ਈਮੇਲ ਵਿੱਚ ਲਿੰਕਾਂ 'ਤੇ ਕਲਿਕ ਕਰਦੇ, ਬਰਾਊਜ਼ਰ-ਅਧਾਰਿਤ ਟੂਲਾਂ ਵਰਤਦੇ, ਜਾਂ ਫਾਈਲਾਂ ਵੈੱਬ ਐਪਸ 'ਤੇ ਅਪਲੋਡ ਕਰਦੇ ਹਨ।
Secure Web Gateway (SWG) ਉਹ ਸ਼੍ਰੇਣੀ ਹੈ ਜੋ ਦਿਨ-ਬਰ-ਦਿਨ ਇੰਟਰਨੈੱਟ ਐਕਸਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ ਹੈ—ਬਿਨਾਂ ਹਰ ਯੂਜ਼ਰ ਦੇ ਟਰੈਫਿਕ ਨੂੰ ਕੇਂਦਰੀ ਦਫਤਰ ਵੱਲ ਮੁੜ ਭੇਜਣ ਦੀ ਲੋੜ ਪੈਂਦੀ।
ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ, SWG ਯੂਜ਼ਰਾਂ ਅਤੇ ਜਨਤਕ ਵੈੱਬ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਚੈਕਪੌਇੰਟ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਡਿਵਾਈਸ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਸਿਧਾ ਭੇਜਣ ਦੀ ਥਾਂ, ਗੇਟਵੇ ਨੀਤੀ ਅਤੇ ਇੰਸਪੈਕਸ਼ਨ ਲਗਾਉਂਦੀ ਹੈ ਤਾਂ ਕਿ ਸੰਠਤ ਸੰਗਠਨਾਂ ਨੂੰ ਮਾਲਵੇਅਰ, ਖਤਰਨਾਕ ਸਾਈਟਾਂ ਅਤੇ ਗਲਤੀ ਨਾਲ ਡਾਟਾ ਲੀਕ ਤੋਂ ਬਚਾਇਆ ਜਾ ਸਕੇ।
ਆਮ ਰੱਖਿਆਤਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਗਤੀ ਉਹ ਸਮਾਂ ਸੀ ਜਦੋਂ ਕੰਮ ਅਸਥਿਰ ਦਫਤਰਾਂ ਤੋਂ ਦੂਰ SaaS, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਮੋਬਾਈਲ ਵੱਲ ਵੱਧ ਗਿਆ। ਜੇ ਯੂਜ਼ਰ ਹਰ ਜਗ੍ਹਾ ਹਨ ਅਤੇ ਐਪ ਹਰ ਜਗ੍ਹਾ ਹਨ, ਤਾਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਪਰਿਮੀਟਰ ਵੱਲ ਮੁੜ ਭੇਜਣਾ ਲੇਟੇਨਸੀ ਅਤੇ ਅੰਧੇ-ਥਾਂਆਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਕਲਾਉਡ-ਡਿਲਿਵਰ SWG ਨਵੀਂ ਹਕੀਕਤ ਦੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ: ਨੀਤੀ ਯੂਜ਼ਰ ਦੇ ਨਾਲ-ਨਾਲ ਜਾਂਦੀ ਹੈ, ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਹਥੇ ਇੰਸਪੈਕਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਨੂੰ ਸਿਰਫ਼ ਹੈੱਡਕੁਆਰਟਰ ਨਹੀਂ, ਸਾਰੇ ਸਥਾਨਾਂ 'ਤੇ ਇਕਸਾਰ ਨਿਯੰਤਰਣ ਮਿਲਦਾ ਹੈ।
VPN ਉਸ ਸਮੇਂ ਲਈ ਬਣੇ ਸਨ ਜਦੋਂ “ਨੈੱਟਵਰਕ ਉੱਤੇ ਹੋਣਾ” ਅਤੇ “ਐਪ ਪਹੁੰਚਣਾ” ਇੱਕੋ ਹੀ ਗੱਲ ਸੀ। ਜਦੋਂ ਐਪ ਕਈ ਕਲਾਉਡਾਂ, SaaS, ਅਤੇ ਘੱਟ-ਬਚੀ ਆਨ-ਪ੍ਰੇਮ ਸਿਸਟਮਾਂ ਵਿੱਚ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ, ਉਹ ਸੋਚ ਟੁੱਟ ਜਾਂਦੀ ਹੈ।
ਐਪ-ਕੇਂਦਰਤ ਐਕਸਸ ਨਿਰਧਾਰਤ ਡਿਫੌਲਟ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਯੂਜ਼ਰ ਨੂੰ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ 'ਤੇ ਡ੍ਰੌਪ ਕਰਨ ਦੀ ਥਾਂ (ਫਿਰ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਸੈਗਮੈਂਟੇਸ਼ਨ ਰੱਖੇਗੀ), ਯੂਜ਼ਰ ਸਿਰਫ਼ ਇੱਕ ਖਾਸ ਐਪ ਨਾਲ ਜੁੜਦਾ ਹੈ।
ਧਾਰਨਾਤਮਕ ਤੌਰ 'ਤੇ, ਇਹ ਇੱਕ ਬ੍ਰੋਕਰਡ ਕਨੈਕਸ਼ਨ ਵਰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਯੂਜ਼ਰ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਕੌਣ ਹੈ ਅਤੇ ਕੀ ਉਸਨੂੰ ਵਰਤਣ ਦੀ ਆਗਿਆ ਹੈ, ਫਿਰ ਉਸ ਐਪ ਲਈ ਇੱਕ ਛੋਟਾ, ਨਿੰਤਰਤ ਰਸਤਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ—ਬਿਨਾਂ ਅੰਦਰੂਨੀ IP ਰੇਂਜਾਂ ਨੂੰ ਇੰਟਰਨੈੱਟ ਉੱਤੇ ਪਬਲਿਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਬਿਨਾਂ ਯੂਜ਼ਰ ਨੂੰ ਵਿਆਪਕ “ਅੰਦਰੂਨੀ” ਦਰਸ਼ਨ ਦੇਣ ਦੇ।
ਨੈੱਟਵਰਕ ਸੈਗਮੈਂਟੇਸ਼ਨ ਸ਼ਕਤੀਸ਼ালী ਹੈ, ਪਰ ਅਸਲ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਇਹ ਨਰਮ ਹੋ ਸਕਦੀ ਹੈ: ਮਰਜਰਾਂ, ਫਲੈਟ VLANs, ਲੈਗੇਸੀ ਐਪ ਅਤੇ ਛੂਟ ਆਮ ਤੌਰ 'ਤੇ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਐਪ ਸੈਗਮੈਂਟੇਸ਼ਨ ਵਿਆਖਿਆ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਾਰੋਬਾਰੀ ਮਨੋਰਥ ਨਾਲ ਮੈਪ ਹੁੰਦੀ ਹੈ:
ਇਸ ਨਾਲ ਇੰਪਲਿਸਿਟ ਭਰੋਸਾ ਘਟਦਾ ਹੈ ਅਤੇ ਐਕਸਸ ਨੀਤੀਆਂ ਪੜ੍ਹਨ ਯੋਗ ਬਣਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦੀ ਆਡੀਟ ਐਪ ਅਤੇ ਯੂਜ਼ਰ ਗਰੁੱਪ ਦੇ ਅਨੁਸਾਰ ਕਰ ਸਕਦੇ ਹੋ ਨਾ ਕਿ ਰੂਟਾਂ ਅਤੇ ਸਬਨੈੱਟਾਂ ਨੂੰ ਟਰੇਸ ਕਰਨਾ।
ਅਧਿਕਤਮ ਟੀਮਾਂ VPN ਨੂੰ ਇਕ ਦਿਨ ਵਿੱਚ ਹਟਾਉਂਦੀਆਂ ਨਹੀਂ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰੋਲਾ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੁੰਦਾ ਹੈ:
ਜਦੋਂ ਐਪ-ਕੇਂਦਰਤ ਐਕਸਸ ਚੰਗੇ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਨਤੀਜੇ ਤੁਰੰਤ ਨਜ਼ਰ ਆ ਜਾਂਦੇ ਹਨ: VPN-ਸਬੰਧੀ ਸਹਾਇਤਾ ਟਿਕਟ ਘੱਟ, ਆਸਾਨ ਪੜ੍ਹਨਯੋਗ ਐਕਸਸ ਨੀਤੀਆਂ, ਅਤੇ ਸੁਧਰੀ ਯੂਜ਼ਰ ਅਨੁਭਵ—ਖਾਸ ਕਰਕੇ ਰਿਮੋਟ ਅਤੇ ਹਾਈਬ੍ਰਿਡ ਕਰਮਚਾਰੀਆਂ ਲਈ ਜਿਹੜੇ ਸਿਰਫ਼ ਐਪ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਪਹਿਲਾਂ “ਨੈੱਟਵਰਕ ਜੁੜਨ” ਦੇ।
ਵਧੀਆ ਸੁਰੱਖਿਆ ਉਤਪਾਦ ਆਪਣੇ ਆਪ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਮਿਆਰ ਨਹੀਂ ਬਣਦੇ। ਅਮਲ ਵਿੱਚ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਦੀ "ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ" ਦਾ ਮਤਲਬ ਉਹ ਰਾਸਤੇ ਹਨ ਜੋ ਇੱਕ ਵੇਂਡਰ ਵੱਡੀਆਂ ਸੰਗਠਨਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ, ਜਿੱਤਣ, ਅਤੇ ਸਫਲਤਾਪੂਰਵਕ ਤੌਰ 'ਤੇ ਤੈਨਾਤ ਹੋਣ ਲਈ ਵਰਤਦਾ ਹੈ—ਅਕਸਰ ਹੋਰ ਕੰਪਨੀਆਂ ਰਾਹੀਂ।
ਸੁਰੱਖਿਆ ਵਿੱਚ, ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:
ਇਹ ਵਿਕਲਪਿਕ ਨਹੀਂ; ਇਹ ਉਹ ਨਲੀਨੀਆਂ ਹਨ ਜੋ ਵੇਂਡਰ ਨੂੰ ਬਜਟਾਂ, ਫੈਸਲੇ ਕਰਨ ਵਾਲਿਆਂ, ਅਤੇ ਨਿਯੁਕਤੀ ਸਮਰੱਥਾ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ।
ਵੱਡੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਧੀਮੇ-ਧੀਮੇ ਖਰੀਦਦਾਰੀ ਕਰਦੀਆਂ ਹਨ। ਪਾਰਟਨਰ ਪੇਸ਼ ਕਰਦੇ ਹਨ:
Zscaler ਜਿਹੇ ਪਲੇਟਫਾਰਮ ਲਈ, ਅੰਗੀਕਾਰ ਅਕਸਰ ਅਸਲੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੰਮ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ—ਉਨਾਂ ਨੂੰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲੇਗੇਸੀ VPN ਪੈਟਰਨਾਂ ਤੋਂ ਹਟਾਉਣਾ, ਆਈਡੈਂਟੀਟੀ ਇਕੱਤਰ ਕਰਨਾ, ਅਤੇ ਨੀਤੀਆਂ ਨੂੰ ਟਿਊਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਪਾਰਟਨਰ ਇਸ ਤਬਦੀਲ ਨੂੰ ਸੰਭਾਲਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਕਲਾਉਡ ਡਿਲਿਵਰੀ ਇੱਕ-ਵਾਰੀ ਇੰਸਟਾਲ ਤੋਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਵਿਸਥਾਰ, ਅਤੇ ਨਵੀਨੀਕਰਨ ਵੱਲ ਕਾਰੋਬਾਰ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਇਸ ਨਾਲ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਵੀ ਬਦਲਦੀ ਹੈ: ਪਾਰਟਨਰ ਸਿਰਫ਼ “ਡਿਲ” ਬੰਦ ਕਰਨ ਵਾਲੇ ਨਹੀਂ ਰਹਿੰਦੇ। ਉਹ ਜਾਰੀ ਰੋਲਆਉਟ ਪਾਰਟਨਰ ਹੋ ਸਕਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਪ੍ਰੇਰਣਾ ਗਾਹਕ ਨਤੀਜਿਆਂ ਨਾਲ ਮਿਲਦੀ ਹੈ—ਜੇ ਪ੍ਰੋਗਰਾਮ ਢੰਗ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।
ਧਿਆਨ ਨਾਲ ਦੇਖੋ ਪਾਰਟਨਰ ਇਨਸੈਂਟਿਵ, ਪਾਰਟਨਰ ਇਨੇਬਲਮੈਂਟ (ਟ੍ਰੇਨਿੰੰਗ, ਪਲੇਅਬੁੱਕ, ਕੋ-ਸੇਲ ਸਹਾਇਤਾ) ਦਾ ਗੁਣਵੱਤਾ, ਅਤੇ ਇਹ ਕਿ ਗਾਹਕ ਸਫਲਤਾ ਹੈਂਡਓਫ਼ ਕਿੰਨੇ ਸਾਫ਼ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਡਿਪਲੋਯਮੈਂਟ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਨਾ ਕਿ ਉਤਪਾਦ ਕਮਜ਼ੋਰ ਹੋਣ ਕਰਕੇ, ਪਰ ਇਸ ਲਈ ਕਿ ਵੇਂਡਰ, ਪਾਰਟਨਰ, ਅਤੇ ਗਾਹਕ ਵਿਚਕਾਰ ਮਾਲਕੀਅਤ ਅਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਸੁਰੱਖਿਆ ਖਰੀਦਦਾਰੀ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਹੀਂ ਹੁੰਦੀ ਕਿ “ਸਾਨੂੰ ਵਧੀਆ ਸੁਰੱਖਿਆ ਚਾਹੀਦੀ ਹੈ।” ਇਹ ਅਕਸਰ ਕਿਸੇ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜੋ ਪੁਰਾਣੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ: ਵੱਧ ਐਪ SaaS ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ, ਬਰਾਂਚ SD-WAN 'ਤੇ ਸਵਿੱਚ ਕਰਦੇ ਹਨ, ਜਾਂ ਰਿਮੋਟ ਵਰਕ ਸਥਾਈ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਹੁਣ ਕੇਂਦਰੀ ਦਫਤਰ ਰਾਹੀਂ ਨਹੀਂ ਲੰਘਦਾ, “ਸਭ ਕੁਝ ਹੈੱਡਕੁਆਰਟਰ 'ਤੇ ਰੱਖੋ” ਮਾਡਲ ਸੁਸਤ ਕੁਨੈਕਸ਼ਨ, ਝੂਠੇ ਛੂਟਾਂ, ਅਤੇ ਅੰਧੇ-ਸਥਾਨ ਪੈਦਾ ਕਰਦਾ ਹੈ।
Zscaler ਨੂੰ ਅਕਸਰ SASE ਅਤੇ SSE ਨਾਲ ਇੱਕੇ ਗੱਲਬਾਤ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਲੇਬਲ ਇਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਸੁਰੱਖਿਆ ਕਿਵੇਂ ਡਿਲਿਵਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
ਅਸਲ “ਫਾਇਦਾ-ਤਰਜਮਾ” ਅਕ੍ਰੋਨਿਮ ਨਹੀਂ—ਇਹ ਸਧਾਰਨ ਆਪਰੇਸ਼ਨ ਦੀ ਸੌਖੀ ਕਾਰਵਾਈ ਹੈ: ਘੱਟ ਆਨ-ਪ੍ਰੇਮ ਬਕਸੇ, ਆਸਾਨ ਨੀਤੀ ਅਪਡੇਟ, ਅਤੇ ਡੇਟਾ ਸੈਂਟਰ ਰਾਹੀਂ ਮੁੜ-ਰਾਊਟ ਕੀਤੇ ਬਿਨਾਂ ਐਪਾਂ ਤੱਕ ਸਿੱਧਾ ਪਹੁੰਚ।
ਕੰਪਨੀ ਆਮ ਤੌਰ 'ਤੇ SSE/SASE-ਸਟਾਇਲ ਪਹੁੰਚਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀ ਹੈ ਜਦੋਂ:
ਜਦੋਂ ਇਹ ਕਾਰਕ ਆਉਂਦੇ ਹਨ, ਸ਼੍ਰੇਣੀ ਕਿਸੇ ਕੰਪਨੀ ਲਈ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਆ ਜਾਂਦੀ ਹੈ—ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਪਹਿਲਾਂ ਹੀ ਬਦਲ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ।
ਜ਼ੀਰੋ-ਟਰੱਸਟ ਪਲੇਟਫਾਰਮ ਖਰੀਦਣਾ ਆਮ ਤੌਰ 'ਤੇ ਆਸਾਨ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਗੰਝਲਦਾਰ ਨੈੱਟਵਰਕ, ਵਿਰਾਸਤ ਐਪਸ, ਅਤੇ ਅਸਲ ਲੋਕਾਂ ਵਿੱਚ ਕੰਮ ਕਰਵਾਉਣਾ ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰੋਜੈਕਟ ਸਫਲ ਜਾਂ ਰੁਕ ਜਾਂਦੇ ਹਨ।
ਵਿਰਾਸਤ ਐਪਸ ਮੁੜ-ਅਵਰਤੀ ਦੋਸ਼ੀ ਹੁੰਦੇ ਹਨ। ਪੁਰਾਣੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਅਕਸਰ ਮੰਨ੍ਹਦੀਆਂ ਹਨ “ਅੰਦਰੂਨੀ = ਭਰੋਸੇਯੋਗ”, ਕਠੋਰ IP allowlists 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ, ਜਾਂ ਟ੍ਰੈਫਿਕ ਦੀ ਜਾਂਚ ਹੋਣ 'ਤੇ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ।
ਹੋਰ ਘਰੜੇ ਮਨੁੱਖੀ ਹਨ: ਬਦਲਾਅ ਪ੍ਰਬੰਧਨ, ਨੀਤੀ ਪੁਨਰ-ਡਿਜ਼ਾਈਨ, ਅਤੇ “ਕੌਣ ਕਿਸਦਾ ਮਾਲਕ ਹੈ” ਵਾਰੇ ਲੜਾਈ। ਨੈੱਟਵਰਕ ਐਕਸਸ ਤੋਂ ਐਪ-ਸਤਹ ਨੀਤੀਆਂ ਵੱਲ ਜਾਨਾ ਟੀਮਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੰਮ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਇਹ ਪੁਰਾਣੇ ਛੇਪੇ ਗਏ ਫੋਰਗਟਨ ਗੈਪ ਨੂੰ ਉਜਾਗਰ ਕਰ ਸਕਦਾ ਹੈ।
ਰੋਲਆਉਟ ਜ਼ਿਆਦਾ ਹਸਤੀ-ਸੁਲਝੇ ਹੋਂਦਿਆਂ ਹਨ ਜਦੋਂ ਸੁਰੱਖਿਆ ਅਕੇਲਾ ਨਹੀਂ ਚਲਦੀ। ਸਮਝੋ ਕਿ ਤੁਹਾਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰਨਾ ਪਵੇਗਾ:
ਇੱਕ ਘੱਟ-ਖਤਰੇ ਵਾਲੀ ਟੈਕਨੀਕ ਸ਼ੁਰੂਆਤ ਇੱਕ ਛੋਟੇ ਸਮੂਹ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਡਿਪਾਰਟਮੈਂਟ ਜਾਂ ਠੇਕੇਦਾਰਾਂ ਦਾ ਇੱਕ ਉਪਸੈੱਟ) ਦੇ ਨਾਲ ਕਰੋ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਸਫਲਤਾ ਮਾਪਦੰਡ ਨਿਰਧਾਰਤ ਕਰੋ: ਘੱਟ VPN ਟਿਕਟ, ਤੇਜ਼ ਐਪ ਪਹੁੰਚ, ਘੱਟ ਖੁੱਲ੍ਹਾ ਹਮਲਾ-ਸਰਫੇਸ, ਜਾਂ ਬਿਹਤਰ ਵਿਜ਼ੀਬਿਲਟੀ।
ਪਾਇਲਟ ਨੂੰ ਇਤਰੈਸ਼ਨਾਂ ਵਿੱਚ ਚਲਾਓ: ਇੱਕ-ਇੱਕ ਐਪ ਸ਼੍ਰੇਣੀ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰੋ, ਨੀਤੀਆਂ ਟਿਊਨ ਕਰੋ, ਫਿਰ ਫੈਲਾਓ। ਮਕਸਦ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣਾ ਹੈ ਬਿਨਾਂ ਪੂਰੀ ਕੰਪਨੀ ਨੂੰ ਟੈਸਟ ਬੈਡ ਬਣਾ ਦਿੱਤੇ।
ਛੇਤੀ ਤੋਂ ਛੇਤੀ ਲਾਗਿੰਗ ਅਤੇ ਟਰਬਲਸ਼ੂਟਿੰਗ ਦੀ ਯੋਜਨਾ ਬਣਾਓ: ਲੌਗ ਕਿੱਥੇ ਰਹਿਣਗੇ, ਕੌਣ ਪੁੱਛਗਿੱਛ ਕਰ ਸਕਦਾ ਹੈ, ਕਿੰਨੀ ਦੇਰ ਰੱਖਣਗੇ, ਅਤੇ ਅਲਰਟਸ_INCIDENT_RESPONSE ਨਾਲ ਕਿਵੇਂ ਜੁੜਨਗੇ। ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਨਹੀਂ ਮਿਲਦੀ ਮਦਦ ਜਦੋਂ “ਐਪ ਬਲੌਕ” ਹੁੰਦਾ, ਤਾਂ ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ—ਭਾਵੇਂ ਸੁਰੱਖਿਆ ਮਾਡਲ ਸਹੀ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤੇ ਅਕਸਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਤੇਜ਼ੀ ਹੈ ਅੰਦਰੂਨੀ ਟੂਲਿੰਗ: ਛੋਟੇ ਪੋਰਟਲ ਜਿਵੇਂ ਐਕਸਪਸ਼ਨ ਰਿਕਵੇਸਟ, ਐਕਸਸ ਮੁਲਾਂਕਣ, ਐਪ ਇਨਵੈਂਟਰੀ, ਰੋਲਆਉਟ ਟ੍ਰੈਕਿੰਗ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਨਾਜ਼ੂਕ “ਗਲੂ ਐਪਾਂ” ਨੂੰ ਖੁਦ ਬਣਾਉਂਦੀਆਂ ਹਨ ਬਜਾਏ ਵੈਂਡਰ ਰੋਡਮੈਪ ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਨੂੰ ਚੈਟ-ਚਲਿਤ ਵਰਕਫਲੋਅ ਰਾਹੀਂ ਤੇਜ਼ੀ ਨਾਲ React-ਅਧਾਰਿਤ ਡੈਸ਼ਬੋਰਡ ਅਤੇ Go/PostgreSQL ਬੈਕਐਂਡ ਵਾਲੀਆਂ ਅੰਦਰੂਨੀ ਵੈੱਬ ਟੂਲਾਂ ਪ੍ਰੋਟੋਟਾਇਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ—ਇਹ ਉਪਯੋਗੀ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਨੀਤੀਆਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਮਾਰੇ ਹੋਏ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਚਾਹੀਦੇ ਹੋ।
ਸੁਰੱਖਿਆ ਕੰਟਰੋਲਾਂ ਨੂੰ ਉਹ ਡਿਵਾਈਸਾਂ ਤੋਂ ਕਲਾਉਡ-ਡਿਲਿਵਰ ਪਲੇਟਫਾਰਮ ਵੱਲ ਬਦਲਣਾ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਧਾਰਨ ਕਰ ਸਕਦਾ ਹੈ—ਪਰ ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਸਥਿਤੀ 'ਤੇ ਨਵੇਂ ਸ਼ਰਤਾਂ ਲੱਗਦੀਆਂ ਹਨ। ਇੱਕ ਚੰਗਾ ਫੈਸਲਾ ਇਹ ਦੇਖਣ ਬਾਰੇ ਹੈ ਕਿ ਨਵੇਂ ਫੇਲਿਅਰ ਮੋਡ ਕੀ ਹਨ।
ਜੇ ਇਕੋ ਪਲੇਟਫਾਰਮ ਵੈੱਬ ਸੁਰੱਖਿਆ, ਪ੍ਰਾਈਵੇਟ ਐਪ ਐਕਸਸ, ਨੀਤੀ ਲਾਗੂਆਈ, ਅਤੇ ਲੌਗਿੰਗ ਦੇ ਰਿਹਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਟੂਲ-ਸਪ੍ਰਾਲ ਘਟਾਉਂਦੇ ਹੋ—ਪਰ ਤੁਸੀਂ ਜੋਖਮ ਵੀ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹੋ। ਇਕਠੇ ਹੋਏ ਕੰਟਰੈਕਟ ਵਿਵਾਦ, ਕੀਮਤ ਵਿੱਚ ਬਦਲਾਅ, ਜਾਂ ਉਤਪਾਦ ਖਾਮੀ ਦਾ ਵਿਆਪਕ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਪਹਿਲਾਂ ਇਹ ਖੰਡਿਤ ਹੁੰਦਾ।
ਕਲਾਉਡ ਸੁਰੱਖਿਆ ਯੂਜ਼ਰਾਂ ਅਤੇ ਐਪਸ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਵਾਧੂ ਹੌਪ ਜੋੜਦੀ ਹੈ। ਜਦੋਂ ਇਹ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ, ਯੂਜ਼ਰਾਂ ਨੂੰ ਫਰਕ ਮਹਿਸੂਸ ਨਹੀਂ ਹੁੰਦਾ। ਜਦੋਂ ਕਿਸੇ ਖੇਤਰ ਵਿੱਚ ਆਉਟੇਜ, ਰੂਟਿੰਗ ਸਮੱਸਿਆ, ਜਾਂ ਸਮਰੱਥਾ ਮੁੱਦਾ ਆ ਜਾਂਦਾ, “ਸੁਰੱਖਿਆ” ਨੂੰ ਲੋਕ “ਇੰਟਰਨੈੱਟ ਡਾਊਨ” ਵਰਗੀ ਹਾਲਤ ਸਮਝ ਲੈਂਦੇ ਹਨ। ਇਹ ਕਿਸੇ ਇੱਕ ਵੇਂਡਰ ਤੱਕ ਸੀਮਤ ਨਹੀਂ—ਇਹ ਹੀ ਹਾਲਤ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਹਮੇਸ਼ਾ-ਚਲਦਾ ਨੈੱਟਵਰਕ 'ਤੇ ਨਿਰਭਰ ਹੋ।
ਜ਼ੀਰੋ-ਟਰੱਸਟ ਜਾਦੂਈਖਿੱਲਾ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਆਜ਼ਾਦ ਨੀਤੀਆਂ (ਬਹੁਤ ਰਾਹਤਦਾਇਕ, ਬਹੁਤ ਰੋਕੂ, ਜਾਂ ਸਮੂਹਾਂ ਵਿੱਚ ਅਸਮੰਜਸ) ਜਾਂ ਅਸੰਗਤ ਨੀਤੀਆਂ ਐਕਸਪੋਜ਼ਰ ਵਧਾ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਕੰਮ ਨੂੰ ਰੋਕ ਸਕਦੀਆਂ ਹਨ। ਜਿੰਨਾ ਲਚਕੀਲਾ ਨੀਤੀ ਇੰਜਣ ਹੋਵੇ, ਉਤਨੀ ਹੀ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਧੀਮੇ-ਧੀਮੇ ਰੋਲਆਉਟ ਮਦਦਗਾਰ ਹਨ: ਇੱਕ ਸਪਸ਼ਟ ਯੂਜ਼ ਕੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਉੱਚ-ਵਾਲੀਉਮ ਇੰਟਰਨੈੱਟ ਐਕਸਸ ਜਾਂ ਇੱਕ ਨਿੱਜੀ ਐਪ ਕੈਟੇਗਰੀ), ਲੇਟੇਨਸੀ ਅਤੇ ਐਕਸਸ ਨਤੀਜੇ ਮਾਪੋ, ਫਿਰ ਫੈਲਾਓ। ਨੀਤੀਆਂ ਸਾਫ਼-ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ, ਨਿਗਰਾਨੀ ਅਤੇ ਅਲਰਟਿੰਗ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਰੇਡੰਡੰਸੀ ਯੋਜਨਾ ਬਣਾਓ (ਮਲਟੀ-ਰੀਜਨ ਰੂਟਿੰਗ, ਬ੍ਰੇਕ-ਗਲਾਸ ਐਕਸਸ, ਅਤੇ ਦਸਤਾਵੇਜ਼ਬੱਧ ਫਾਲਬੈਕ ਰਸਤੇ)।
ਜਾਣੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਡਾਟਾ ਪ੍ਰਕਾਰਾਂ ਦੀ ਰੱਖਿਆ ਕਰ ਰਹੇ ਹੋ (ਨਿਯਮਤ vs ਆਮ), ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਕੰਪਲਾਇੰਸ ਲੋੜਾਂ ਨਾਲ ਮਿਲਾਉ, ਅਤੇ ਨਿਯਮਤ ਐਕਸਸ ਸਮੀਖਿਆਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਲਕੜੀ ਮਕਸਦ ਡਰ-ਅਧਾਰਿਤ ਖਰੀਦਦਾਰੀ ਨਹੀਂ—ਇਹ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਨਵਾਂ ਮਾਡਲ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪੇਸ਼ਗੀ ਕਰਕੇ ਨਾਕਾਮ ਹੋਵੇ।
Zscaler ਦਾ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਪਾਠ ਧਿਆਨ ਹੈ: ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਨੂੰ ਕਲਾਉਡ ਵੱਲ ਲਿਜਾਓ ਅਤੇ ਐਕਸਸ ਨੂੰ ਪਹਿਚਾਣ-ਚਲਿਤ ਬਣਾਵੋ। ਜਦੋਂ ਵੇਂਡਰਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ (ਜਾਂ ਇੱਕ ਬਣਾ ਰਹੇ ਹੋ), ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਪੁੱਛੋ: "ਉਹ ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਦਾਅਵਾ ਕੀ ਹੈ ਜੋ ਬਾਕੀ ਸਭ ਕੁਝ ਸਧਾ ਕਰਦਾ ਹੈ?" ਜੇ ਜਵਾਬ "ਉਤੇ ਨਿਰਭਰ" ਹੈ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਲਾਗਤ, ਰੋਲਆਉਟ ਸਮਾਂ ਅਤੇ ਛੂਟਾਂ ਵਿੱਚ ਜਟਿਲਤਾ ਆਉਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ।
"ਜ਼ੀਰੋ-ਟਰੱਸਟ" ਨੇ ਕਿਰਿਆ ਕੀਤੀ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਵਾਅਦਾ ਬਣ ਗਿਆ: ਘੱਟ ਇੰਪਲਿਸਿਟ ਭਰੋਸੇ, ਘੱਟ ਨੈੱਟਵਰਕ ਪਲੰਬਿੰਗ, ਅਤੇ ਜਦੋਂ ਐਪ ਆਫ-ਪ੍ਰੇਮ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਵਧੀਆ ਨਿਯੰਤਰਣ। ਟੀਮਾਂ ਲਈ, ਇਹ ਮਤਲਬ ਹੈ ਨਤੀਜਿਆਂ ਨੂੰ ਖਰੀਦੋ, ਨਾ ਕਿ ਬਜ਼ਵਰਡਸ। ਆਪਣੀ ਚਾਹੀਦੀ ਨਤੀਜੇ ਲਿਖੋ (ਉਦਾਹਰਨ: "ਕੋਈ ਇੰਬਾਊਂਡ ਪਹੁੰਚ ਨਹੀਂ", "ਐਪਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ", "ਰਿਮੋਟ ਯੂਜ਼ਰਾਂ ਲਈ ਇਕਸਾਰ ਨੀਤੀ") ਅਤੇ ਹਰ ਇਕ ਨੂੰ ਪਰਖਣਯੋਗ ਸਮਰੱਥਾ ਨਾਲ ਜੋੜੋ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸੁਰੱਖਿਆ ਭਰੋਸਾ ਨੈੱਟਵਰਕਾਂ ਰਾਹੀਂ ਫੈਲਦੀ ਹੈ: ਰੀਸੇਲਰ, GSIs, MSPs, ਅਤੇ ਕਲਾਉਡ ਮਾਰਕੀਟਪਲੇਸ। ਫਾਉਂਡਰ ਇਸਨੂੰ ਨਕਲ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਪਾਰਟਨਰ-ਰੈਡੀ ਉਤਪਾਦ ਛੇਤੀ ਬਣਾਓ—ਸਾਫ਼ ਪੈਕੇਜਿੰਗ, ਭਵਿੱਖੀ ਮਾਰਜਿਨ, ਡਿਪਲੋਯਮੈਂਟ ਪਲੇਅਬੁੱਕ, ਅਤੇ ਸਾਂਝੇ ਮੈਟ੍ਰਿਕਸ। ਸੁਰੱਖਿਆ ਲੀਡਰ ਵੀ ਪਾਰਟਨਰਾਂ ਨੂੰ ਲਾਭ ਉਠਾਓ: ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲਾਅ ਪ੍ਰਬੰਧਨ, ਆਈਡੈਂਟੀਟੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਪੇਜ਼ਡ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਲਈ ਵਰਤੋ ਬਜਾਏ ਹਰ ਟੀਮ ਨੂੰ ਨਵੀਂ ਯੋਗਤਾ ਸਿਖਾਉਣ ਦੇ।
ਇੱਕ ਉੱਚ-ਵਾਲੀਉਮ ਯੂਜ਼ ਕੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਅਕਸਰ ਇੰਟਰਨੈੱਟ ਐਕਸਸ ਜਾਂ ਇੱਕ ਇੱਕਲ-ਲੋੜੀਂਦੀ ਐਪ), ਪਹਿਲਾਂ/ਬਾਅਦ ਮਾਪੋ, ਅਤੇ ਫੈਲਾਓ।
ਮੁੱਖ ਰੋਲਆਇਟ ਸਵਾਲ:
ਕੁਝ ਵੀ "ਸਿਰਫ਼ ਸੁਰੱਖਿਆ ਵੇਚੋ" ਨਹੀਂ—ਇੱਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਾਹ ਵੀ ਵੇਚੋ। ਜਿੱਤਨ ਵਾਲੀ ਕਹਾਣੀ ਆਮ ਤੌਰ 'ਤੇ: ਦਰਦ → ਸਭ ਤੋਂ ਸਧਾਰਨ ਪਹਿਲਾ ਕਦਮ → ਮਾਪਯੋਗ ਜੇਤੂ → ਵਿਸਥਾਰ। ਉਹ ਔਨਬੋਰਡਿੰਗ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਬਣਾਓ ਜੋ 30–60 ਦਿਨਾਂ ਵਿੱਚ ਮੁੱਲ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੋਵੇ।
ਫਾਉਂਡਰ-ਫ੍ਰੈਂਡਲੀ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਮੁੱਖ ਉਤਪਾਦ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਓ ਜੋੜੀਵਾਰ ਐਪ (ਅਸੈਸਮੈਂਟ ਵਰਕਫਲੋਜ਼, ਮਾਈਗ੍ਰੇਸ਼ਨ ਟ੍ਰੈਕਰ, ROI ਕੈਲਕੁਲੇਟਰ, ਪਾਰਟਨਰ ਪੋਰਟਲ)। ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਪੂਰੇ ਲੈਗੇਸੀ ਡੈਵ ਪਾਈਪਲਾਈਨ ਬਿਨਾਂ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਬਾਤ-ਚਿੱਤ ਤੋਂ ਪੂਰੇ-ਸਟੈਕ ਐਪ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ—ਇਹ ਤੁਹਾਡੀ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਮੋਸ਼ਨ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਾਉਣ ਲਈ ਲਾਭਦਾਈ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਡੂੰਘਾਈ ਵਿੱਚ ਜਾਓਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਬਲੌਗ 'zero-trust-basics' ਅਤੇ ਬਲੌਗ 'sase-vs-sse-overview' ਦੇ ਲੇਖ ਵੇਖੋ। ਪੈਕੇਜਿੰਗ ਵਿਚਾਰਾਂ ਲਈ, pricing ਵੇਖੋ।
ਜ਼ੀਰੋ-ਟਰੱਸਟ ਉਹ ਰਵਾਇਤ ਹੈ ਜਿਸਦੇ ਅਨੁਸਾਰ ਐਕਸਸ ਫੈਸਲੇ ਹਰ ਬੇਨਤੀ ਤੇ ਪਹਿਚਾਣ, ਡਿਵਾਈਸ ਦੀ ਹਾਲਤ ਅਤੇ ਸੰਦਰਭ ਦੇ ਆਧਾਰ 'ਤੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਇਸ ਆਧਾਰ 'ਤੇ ਕਿ ਕੁਛ “ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ” ਹੈ ਇਸ ਲਈ ਸੁਰੱਖਿਅਤ ਸਮਝਿਆ ਜਾਵੇ। ਵਾਸਤਵ ਵਿੱਚ ਇਹਦਾ ਮਤਲਬ ਹੈ:
ਰਵਾਇਤੀ VPN ਅਕਸਰ ਯੂਜ਼ਰ ਨੂੰ “ਨੈੱਟਵਰਕ ਉੱਤੇ” ਰੱਖ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਬੇਤਰਤੀਬੀ ਨਾਲ ਜ਼ਿਆਦਾ ਸਿਸਟਮਾਂ ਦਾ ਪਹੁੰਚ ਹੋ ਸਕਦਾ ਹੈ। ਐਪ-ਕੇਂਦਰਤ ਐਕਸਸ ਮਾਡਲ ਇਹ ਤਰੀਕਾ ਉਲਟਦਾ ਹੈ:
“Inline” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਆਪਣੀ ਮਨਜ਼ਿਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੁਰੱਖਿਆ ਚੈਕਪੌਇੰਟ ਰਾਹੀਂ ਰੁੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕਲਾਉਡ-ਡਿਲਿਵਰ ਕੀਤੇ ਮਾਡਲ ਵਿੱਚ, ਇਹ ਚੈਕਪੌਇੰਟ ਇੱਕ ਨੇੜੇ ਦੇ PoP (Point of Presence) ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਦਾਤਾ ਇਸ ਤਰ੍ਹਾਂ ਕਰ ਸਕਦਾ ਹੈ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਇਕਸਾਰ ਸੁਰੱਖਿਆ ਹੋਵੇ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਹੈੱਡਕੁਾਰਟਰਨਾਂ ਵੱਲ ਵਾਪਸ ਭੇਜਣ ਦੇ।
ਬੈਕਹੌਲਿੰਗ ਰਿਮੋਟ ਯੂਜ਼ਰ ਦੇ ਵੈੱਬ ਅਤੇ SaaS ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰੀਖਿਆ ਲਈ ਕੇਂਦਰੀ ਡੇਟਾ ਸੈਂਟਰ ਵੱਲ ਭੇਜਦੀ ਹੈ ਅਤੇ ਫਿਰ ਇੰਟਰਨੈੱਟ ਵੱਲ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਇਹ ਅਕਸਰ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ:
Secure Web Gateway (SWG) ਯੂਜ਼ਰਾਂ ਨੂੰ ਇੰਟਰਨੈੱਟ ਬਰਾਊਜ਼ਿੰਗ ਅਤੇ SaaS ਐਪਸ ਵਰਤੋਂ ਦੌਰਾਨ ਸੁਰੱਖਿਆ ਦਿੰਦਾ ਹੈ। ਆਮ SWG ਸਮਰੱਥਾਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਇਹ ਖਾਸ ਕਰਕੇ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਬਹੁਤ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਇੰਟਰਨੈੱਟ-ਬਾਊਂਡ ਹੁੰਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਇਕ ਸਿੰਗਲ ਕਾਰਪੋਰੇਟ ਫਾਇਰਵਾਲ ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਬੈਠੇ ਹੁੰਦੇ।
ਕਲਾਉਡ-ਡਿਲਿਵਰ ਕੀਤੇ ਸੁਰੱਖਿਆ ਕੰਟਰੋਲ ਆਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਧਾਰਣ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਸ ਨਾਲ ਤੁਹਾਡੀ ਨਿਰਭਰਤਾ ਦੇ ਨਵੇਂ ਜੋਖਮ ਆ ਜਾਂਦੇ ਹਨ। ਮੁੱਖ ਕਾਰੋਬਾਰੀ-ਪਹਲੂ ਜੋ ਮੁਲਾਂਕਣ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ:
ਇੱਕ ਨੀਮ-ਖਤਰੇ ਵਾਲਾ ਪਾਇਲਟ ਆਮ ਤੌਰ 'ਤੇ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਤੰਗ ਸਕੋਪ ਵਾਲਾ ਅਤੇ ਮਾਪਯੋਗ ਹੋਵੇ:
ਮਕਸਦ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣਾ ਹੈ ਬਿਨਾਂ ਪੂਰੀ ਕੰਪਨੀ ਨੂੰ ਟੈਸਟ ਵਾਤਾਵਰਣ ਬਣਾ ਦਿੱਤੇ।
ਗਲਤ ਸੰਰਚਨਾ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਜੋਖਮ ਹੈ ਕਿਉਂਕਿ “ਨੈੱਟਵਰਕ ਐਕਸਸ” ਤੋਂ “ਐਪ/ਨੀਤੀ ਐਕਸਸ” ਵੱਲ ਜਾਣ ਨਾਲ ਟੀਮਾਂ ਨੂੰ ਨੀਤੀਆਂ ਬੜੀ ਸੋਚ-ਵਿਚਾਰ ਨਾਲ ਲਿਖਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ। ਜੋਖਮ ਘਟਾਉਣ ਲਈ:
SSE ਉਹ ਕਲਾਉਡ-ਡਿਲਿਵਰ ਕੀਤੇ ਸੁਰੱਖਿਆ ਕੰਟਰੋਲ ਹਨ (ਜਿਵੇਂ SWG ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਐਪ ਐਕਸਸ) ਜੋ ਯੂਜ਼ਰਾਂ ਦੇ ਨੇੜੇ 'ਐਜ਼-ਏ-ਸਰਵਿਸ' ਮਿਲਦੇ ਹਨ। SASE ਉਹੀ ਸੋਚ ਹੈ ਪਰ ਜਿਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਪੱਖ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ (ਅਕਸਰ SD-WAN), ਤਾਂ ਜੋ ਕੰਨੀਕਟੀਵਿਟੀ ਅਤੇ ਸੁਰੱਖਿਆ ਇਕੱਠੇ ਸੋਚੀ ਜਾਣ।
ਖਰੀਦਦਾਰੀ ਹਿਸਾਬ ਨਾਲ:
ਵੱਡੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਅਕਸਰ ਪਾਰਟਨਰਾਂ ਰਾਹੀਂ ਖਰੀਦਦਾਰੀ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਇੰਪਲੀਮੇਨਟੇਸ਼ਨ ਸਮਰੱਥਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਚੈਨਲ ਪਾਰਟਨਰ, SIs ਅਤੇ MSPs ਇਹ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:
ਇੱਕ ਮਜ਼ਬੂਤ ਸਾਥੀ ਪਰਿਬੇਸ਼ ਦਿਰਘਕਾਲੀਨ ਤੌਰ 'ਤੇ ਤਯਾਰ ਹੋਣ ਜਾਂ ਅਲਮਲੀ ਹੋਣ ਦਾ ਫੈਸਲਾ ਕਰ ਸਕਦਾ ਹੈ।