ਫੀਲਡ ਡਿਵਾਈਸ, TLS ਅਤੇ VPN: ਕਿਹੜੀ ਸੀਮਾ ਕੀ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ

ਇੱਕ ਫੀਲਡ ਡਿਵਾਈਸ ਸੇਵਾ ਨਾਲ ਕਨੈਕਸ਼ਨ ਖੋਲੱਹਦਾ ਹੈ ਅਤੇ ਡਿਜ਼ਾਈਨ ਦਾ ਸਵਾਲ VPN ਅਤੇ TLS ਵਿੱਚਕਰ ਚੋਣ ਵਜੋਂ ਆਉੰਦਾ ਹੈ। ਇਹ ਢਾੰਚਾ ਗ਼ਲਤ ਹੈ, ਕਿਉੰਕਿ ਦੋਵੇਂ ਵੱਖਰਾ ਕੰਮ ਕਰਦੇ ਹਨ। TLS ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਗੱਲਬਾਤ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ; ਜਦਕਿ VPN ਪਹੁੰਚ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਥੀਆਂ ਵਿੱਚਕਰ ਪੈਕਟ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ. ਡਿਵਾਈਸ ਤੋਂ ਬਾਹਰ ਵੱਲ ਕਨੈਕਸ਼ਨ ਦਾ ਪਿੱਛਾ ਕਰੋ ਅਤੇ ਹਰ ਪਰਤ ਦਾ ਆਪਣਾ ਜਵਾਬ ਹੈ।

ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ TLS ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਵੀ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿਸ ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ।

ਪਤਾ ਲਗਾਓ ਕਿ TLS ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ

ਡਿਵਾਈਸ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਹੈੰਡਸ਼ੇਕ ਪੂਰਾ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਤਕ ਕਨੈਕਸ਼ਨ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਜੇ ਪ੍ਰੌਕਸੀ ਮੈਨਫ਼੍ਰੇਮ ਤੋਂ ਪਹਿਲਾਂ TLS ਖ਼ਤਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਅਤ ਮਾਰਗ ਪ੍ਰੌਕਸੀ ਤੇ ਹੀ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ। ਬਾਕੀ ਛਾਲ ਨੂੰ ਆਪਣੀ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਆ ਚਾਹੀਦੀ ਹੈ।

ਇਸ ਨੂੰ ਅੰਦਾਜ਼ੇ ਦੇ ਆਧਾਰ 'ਤੇ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤਕ' ਕਹਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਖਾਲੀ ਥਾਂ ਨੂੰ ਸਵੀਕਾਰਦੀ ਹੈ। ਅੰਤ ਬਿੰਦੂ ਅਤੇ ਭਰੋਸੇ ਦਾ ਲੰਗਰ ਇੱਕ ਹੀ ਚਿੱਤਰ ਵਿੱਚ ਖਿੱਚੋ।

TLS ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬ ਲੈ ਕੇ ਜਾੰਦਾ ਹੈ, ਇਸ ਲਈ ਦੁਵੱਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੁਭਾਵਿਕ ਤੌਰ 'ਤੇ TLS ਦੀ ਥਾਂ VPN ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਉਲੱਟਾ ਵੀ ਸੱਚ ਹੈ: ਉਸੇ ਡਿਵਾਈਸ 'ਤੇ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਤੈਨਾਤੀ ਨੂੰ ਅਜੇ ਵੀ VPN ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਡਿਵਾਈਸ ਨੂੰ ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ

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

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਕੁੰਜੀ ਸੁਰੱਖਿਆ, ਨਵੀਨੀਕਰਨ, ਰੱਦ ਕਰਨ ਅਤੇ ਬਹਾਲੀ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਅਸਫਲ ਨਵੀਨੀਕਰਨ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਦਰਜ ਨਾ ਹੋ ਸਕਣ ਵਾਲਾ ਖੇਤਰੀ ਡਿਵਾਈਸ ਮੌਕਾ ਫੇਰੀ ਬਣ ਜਾੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਲਾਗਤ ਹੈੰਡਸ਼ੇਕ ਨਾਲੋਂ ਵੱਧ ਡਿਜ਼ਾਈਨ ਨੂੰ ਆਕਾਰ ਦਿੰਦੀ ਹੈ।

ਸਮਰਥਿਤ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਮੌਜੂਦਾ ਮਾਰਗਦਰਸ਼ਨ ਵਰਤੋ। ਆਧੁਨਿਕ TLS ਤੈਨਾਤੀ ਮਾਰਗਦਰਸ਼ਨ TLS 1.0 ਅਤੇ 1.1 'ਤੇ ਗੱਲਬਾਤ 'ਤੇ ਰੋਕ ਲਾਉੰਦੇ ਹਨ, ਅਤੇ ਪੁਰਾਣੀ ਡਿਜ਼ਾਈਨ ਨੋਟ ਵਿੱਚ TLSv1 ਦਾ ਜ਼ਿਕਰ ਲੋੜ ਨਹੀਂ ਹੈ।

ਹੈੰਡਸ਼ੇਕ ਅਸਫਲ ਹੋਣ 'ਤੇ ਬੰਦ ਰਹੋ

ਅਸਫਲ ਹੈੰਡਸ਼ੇਕ ਜਾਂ ਅਸਫਲ ਪਛਾਣ ਜਾੰਚ ਚੁੱਪਚਾਪ ਮੂਲ ਸਪਸ਼ਟ-ਪਾਠ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਆਉਣੀ ਚਾਹੀਦੀ। ਉਹੀ ਵਾਪਸੀ ਉਹ ਕਮਜ਼ੋਰੀ ਹੈ ਜੋ TLS ਕੰਮ ਨੇ ਬੰਦ ਕਰਨੀ ਸੀ। ਅਸਫਲਤਾ ਨੂੰ ਡਿਵਾਈਸ ਆਪਰੇਟਰ ਅਤੇ ਸੇਵਾ ਲਈ ਦਿੱਸਣਯੋਗ ਬਣਾਓ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਕੰਮਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਚੈਨਲ ਲਾਜ਼ਮੀ ਕਰੋ। ਫਿਰ ਐਪਲੀਕੇਸ਼ਨ ਅਧਿਕਾਰ ਨਿਰਧਾਰਤ ਕਰੇ ਕਿ ਪ੍ਰਮਾਣਿਤ ਡਿਵਾਈਸ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।

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

ਵਾਪਸੀ ਦਾ ਨਿਯਮ ਲਿਖੋ। “ਜੇ ਹੈੰਡਸ਼ੇਕ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹ TLS ਤੋਂ ਬਿਨਾਂ ਦੁਬਾਰਾ ਜੁੜਦਾ ਹੈ” ਇੱਕ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

VPN ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਕੰਮ ਦਿਓ ਜੋ ਇਹ ਕਰ ਸਕਦਾ ਹੈ

VPN ਪਹੁੰਚ ਨੂੰ ਸੀਮਿਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਸਾਥੀ ਤੱਕ ਪੈਕਟ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕਦਾ ਹੈ। TLS ਚੁਣੇ ਅੰਤ ਬਿੰਦੂ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੰਬੰਧ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਦੇ ਅੰਤ ਬਿੰਦੂ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅੰਤ ਬਿੰਦੂ ਦੇ ਸੰਗ੍ਰਹਿਤ ਡੇਟਾ ਜਾਂ ਪ੍ਰਬੰਧਕੀ ਪਹੁੰਚ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕਰਦਾ।

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