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

ਲੌਗਇਨ ਸਕ੍ਰੀਨ ਤੋਂ ਬਾਹਰ ਵੱਲ ਤੁਰੋ

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

ਇਹ ਵੱਖਰਾਅ ਹੀ ਉਹ ਸਵਾਲ ਹੈ ਜਿਸਦਾ ਜਵਾਬ ਦੇਣਾ ਯੋਗ ਹੈ। ਸਾਈਟ VPN ਤਦ ਹੀ ਬੇਲੋੜੀ ਹੈ ਜਦੋਂ ਉਸ ਦੂਜੇ ਤੁਰਨ ਦੇ ਹਰ ਚੈਨਲ ਕੋਲ ਆਪਣੇ ਆਪ ਖੜ੍ਹੀ ਦਾਖਲਾ ਅਤੇ ਅਧਿਕਾਰ ਨੀਤੀ ਹੋਵੇ।

ਪੰਜ ਚੈਨਲ ਜੋ ਐਪ ਲੌਗਇਨ ਕਦੇ ਨਹੀਂ ਢੱਕਦਾ

ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਇੱਕ ਸੂਚੀ ਟੈਂਪਲੇਟ ਹੈ, ਤੈਨਾਤੀ ਜਾਂਚ ਸੂਚੀ ਨਹੀਂ। ਦੂਜਾ ਕਾਲਮ ਉਸ ਨਾਲ ਭਰੋ ਜੋ ਤੁਹਾਡਾ ਵਾਤਾਵਰਨ ਅੱਜ ਸੱਚਮੁੱਚ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ChannelAccess decision to identify
Application APIAccepted TLS peer, application identity, permitted operations
Operating-system administrationApproved entry path, administrative identity, host permissions
Database maintenanceDatabase identity, protected connection, authorized maintenance role
Backup and restoreService identity, allowed source, access to stored copies
Cloud control planeAccount and role permissions governing infrastructure changes

ਇੱਕੋ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਸਾਂਝਾ ਕਰਨ ਨਾਲ ਇਹ ਅਧਿਕਾਰ ਇੱਕ ਨਹੀਂ ਹੁੰਦੇ। API ਬੇਨਤੀ ਭੇਜ ਸਕਣ ਵਾਲਾ ਵਰਤੋਂਕਾਰ ਇਸ ਨਾਲ VM ਡਿਸਕ ਬਦਲਣ ਜਾਂ ਐਪ ਦੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਨਾਲ ਡੇਟਾਬੇਸ ਬਹਾਲ ਕਰਨ ਦਾ ਅਧਿਕਾਰੀ ਨਹੀਂ ਹੁੰਦਾ। NIST ਜ਼ੀਰੋ-ਟਰੱਸਟ ਆਰਕੀਟੈਕਚਰ ਸੰਖੇਪ ਵਿੱਚ ਠੀਕ ਇਸੇ ਕਾਰਨ ਸਰੋਤ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਨੂੰ ਨੈੱਟਵਰਕ ਸਥਾਨ ਤੋਂ ਵੱਖ ਰੱਖਦਾ ਹੈ।

ਟਿਕਟ ਪੜ੍ਹ ਸਕਣ ਵਾਲਾ ਸਹਾਇਤਾ ਇੰਜੀਨੀਅਰ ਇਸ ਨਾਲ ਉਸਦੇ ਪਿੱਛੇ ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਕੰਸੋਲ ਖੋਲ੍ਹਣ ਦਾ ਅਧਿਕਾਰੀ ਨਹੀਂ ਹੁੰਦਾ।

ਰਾਹ ਤਦ ਹੀ ਅਸਲੀ ਹੈ ਜਦੋਂ ਬਦਲ ਬੰਦ ਰਹੇ

ਨਿੱਜੀ ਪ੍ਰਬੰਧਕੀ ਸਰੋਤਿਆਂ ਤੱਕ ਪਹੁੰਚ ਸੀਮਤ ਕਰਨਾ ਸਾਈਟ VPN ਦਾ ਜਾਇਜ਼ ਬਦਲ ਹੈ, ਬਸ਼ਰਤੇ ਸੀਮਾ ਲਾਗੂ ਕੀਤੀ ਜਾਵੇ, ਸਿਰਫ਼ ਖਿੱਚੀ ਨਾ ਜਾਵੇ। ਆਮ ਅਸਫਲਤਾ ਉਹ ਬਦਲਵਾਂ ਸਰੋਤਾ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਯਾਦ ਨਹੀਂ ਰੱਖਿਆ: ਸਾਰੇ ਇੰਟਰਫੇਸ ਨਾਲ ਅਜੇ ਵੀ ਬੱਝੀ ਸੇਵਾ, ਠੇਕੇਦਾਰ ਲਈ ਖੋਲ੍ਹਿਆ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨਿਯਮ, ਇੰਟਰਨੈੱਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਪ੍ਰਬੰਧਨ ਪੋਰਟ।

ਚਿੱਤਰ ਨਹੀਂ, ਸਰੋਤਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ। ਹੋਸਟ 'ਤੇ ss -ltnp ਨਾਲ ਸੂਚੀ ਬਣਾਓ ਕਿ ਸੱਚਮੁੱਚ ਕੀ ਬੱਝਿਆ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰਬੰਧਕੀ ਪੋਰਟ ਨਿੱਜੀ ਪਤੇ 'ਤੇ ਹਨ। ਕਲਾਊਡ ਕੰਸੋਲ ਵਿੱਚ ਕੰਮ ਭਾਰ ਉਪਜਾਲ ਲਈ ਆਉਣ ਵਾਲੇ ਨਿਯਮ ਪੜ੍ਹੋ ਅਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰਬੰਧਕੀ ਚੀਜ਼ 'ਤੇ 0.0.0.0/0 ਲੱਭੋ। ਫਿਰ ਨਿੱਜੀ ਰਾਹ ਤੋਂ ਬਾਹਰੋਂ ਕਨੈਕਸ਼ਨ ਅਜ਼ਮਾਓ, ਕਿਉਂਕਿ ਉਹੀ ਪਰਖ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।

SSH 'ਤੇ ਇੱਕ ਵੀ ਦੁਨੀਆਂ ਲਈ ਖੁੱਲ੍ਹਾ ਨਿਯਮ ਟਨਲ ਡਿਜ਼ਾਈਨ ਦੀ ਹਰ ਦਲੀਲ ਰੱਦ ਕਰਦਾ ਹੈ।

ਡਿਜ਼ਾਈਨ ਦੀ ਤੁਲਨਾ ਤੋਂ ਪਹਿਲਾਂ ਨਕਸ਼ਾ ਲਿਖੋ

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

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

ਸਾਈਟ VPN ਅਜੇ ਵੀ ਕਿੱਥੇ ਆਪਣੀ ਥਾਂ ਕਮਾਉਂਦੀ ਹੈ

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

ਇਹ ਇੱਕੋ ਜਵਾਬ ਨਹੀਂ ਹੈ। ਹਰ ਸਰੋਤ ਲਈ ਅਧਿਕਾਰ ਖਤਮ ਕਰਨ ਵਾਲਾ ਗੇਟਵੇ ਪੂਰੇ ਉਪਜਾਲ ਦੇ ਟਨਲ ਨਾਲੋਂ ਤੰਗ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਸਾਂਝੇ ਜੰਪ ਹੋਸਟ ਨਾਲੋਂ ਬਿਹਤਰ ਆਡਿਟ ਟ੍ਰੇਲ ਛੱਡਦਾ ਹੈ।

ਕੰਮ ਦਾ ਕ੍ਰਮ: ਸੂਚੀ ਪੂਰੀ ਕਰੋ, ਬਦਲ ਬੰਦ ਕਰੋ, ਹਰ ਕਤਾਰ ਲਈ ਇੱਕ ਇਨਕਾਰ ਪਰਖੋ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਟਨਲ ਹਟਾਓ। ਜੇ ਕੋਈ ਕਤਾਰ ਇਨਕਾਰ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਤਾਂ ਹੋ ਸਕਣ ਤੱਕ ਨਿੱਜੀ ਰਾਹ ਰੱਖੋ।

ਸੰਬੰਧਿਤ ਲੇਖ