TLS, ਨੈੱਟਵਰਕ ਪ੍ਰਵੇਸ਼ ਅਤੇ SQL ਅਧਿਕਾਰ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ
ਕਨੈਕਸ਼ਨ ਐਨਕ੍ਰਿਪਟ ਕਰਨਾ, ਸਰੋਤ ਨੂੰ ਆਗਿਆ ਦੇਣਾ ਅਤੇ ਟੇਬਲ ਦੇਣਾ ਤਿੰਨ ਫੈਸਲੇ ਹਨ। TLS VPN ਦੀ ਥਾਂ ਲੈ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਵੇਖੋ।
ਕੋਈ ਗਾਹਕ ਨੂੰ PostgreSQL ਲੌਗਇਨ ਦੇਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਖਰਚੇ ਦਾ ਦਾਅਵਾ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਐਨਕ੍ਰਿਪਟ ਹੋ ਕੇ ਜਾਵੇ। ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਕ ਨੂੰ ਅਸਲੀ SQL ਸੈਸ਼ਨ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਹੋਰ ਇਸ ਦੀ ਥਾਂ ਵੈੱਬ ਫਾਰਮ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਸੁਝਾਅ ਗਲਤ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਸ ਕਿਰਿਆ ਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ ਜੋ ਗਾਹਕ ਅਸਲ ਵਿੱਚ ਕਰਦਾ ਹੈ। ਤਿੰਨੇ ਫੈਸਲੇ ਕ੍ਰਮ ਵਿੱਚ ਵੇਖੋ ਅਤੇ TLS VPN ਦੀ ਥਾਂ ਲੈ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਸਵਾਲ ਆਪਣੇ ਆਪ ਜਵਾਬ ਦੇ ਦੇਵੇਗਾ।
ਉਸ ਕਿਰਿਆ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਗਾਹਕ ਨੂੰ ਚਾਹੀਦੀ ਹੈ
ਲਿਖੋ ਕਿ ਗਾਹਕ ਨੂੰ ਕੀ ਹਾਸਲ ਕਰਨਾ ਹੈ। ਦਾਅਵਾ ਜਮ੍ਹਾਂ ਕਰਨਾ, ਰਿਪੋਰਟ ਦੀ ਇੱਕ ਕਤਾਰ ਪੜ੍ਹਨਾ ਅਤੇ ਤੁਰੰਤ ਕਵੈਰੀ ਚਲਾਉਣਾ ਤਿੰਨ ਵੱਖਰੀਆਂ ਕਿਰਿਆਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਖ਼ਤਰੇ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਖਰੇ ਹਨ।
ਫਿਰ ਲਿਖੋ ਕਿ ਬੇਨਤੀ ਕੌਣ ਕਰ ਰਿਹਾ ਹੈ। ਗਾਹਕ, ਸਹਾਇਤਾ ਏਜੰਟ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕ ਇੱਕੋ ਟੇਬਲ ਨੂੰ ਛੂਹਣ ਪਰ ਵੀ ਇੱਕ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੇ। ਇਹ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਗਾਹਕ ਨੂੰ ਕਵੈਰੀ ਭਾਸ਼ਾ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਕਦੇ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਵਾਬਾਂ ਦੀ ਜੋੜੀ ਇੰਟਰਫ਼ੇਸ ਤੈਅ ਕਰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਅਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਬਾਰੇ ਬਹੁਤੀ ਬਹਿਸ ਅਸਲ ਵਿੱਚ ਇਸ ਬਾਰੇ ਬਹਿਸ ਹੈ ਕਿ ਕਿਹੜਾ ਇੰਟਰਫ਼ੇਸ ਚੁਣਿਆ ਗਿਆ।
ਤਿੰਨ ਨਿਯੰਤਰਣ, ਤਿੰਨ ਫੈਸਲੇ
ਪ੍ਰਮਾਣਿਤ TLS ਕਨੈਕਸ਼ਨ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ TLS ਪਛਾਣਾਂ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਨੈੱਟਵਰਕ ਪ੍ਰਵੇਸ਼ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਸਰੋਤ ਸੁਣਨ ਵਾਲੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਡੇਟਾਬੇਸ ਅਧਿਕਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਭੂਮਿਕਾ ਕਿਹੜੀਆਂ ਵਸਤੂਆਂ ਅਤੇ ਕਿਰਿਆਵਾਂ ਵਰਤ ਸਕਦੀ ਹੈ।
ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੂਜਿਆਂ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਜੋ ਟੇਬਲ ਸਪਸ਼ਟ ਕਰਦੀ ਹੈ।
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
ਦੂਜੀ ਕਤਾਰ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਕਤਾਰ ਪੜ੍ਹੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਡਿਜ਼ਾਈਨ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਨਿਯੰਤਰਣ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਥਾਂ ਮੰਨ ਲਿਆ ਗਿਆ ਸੀ।
ਸਿੱਧਾ SQL ਡੇਟਾਬੇਸ ਨੀਤੀ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਰੱਖਦਾ ਹੈ
ਮਨਜ਼ੂਰ ਸਿੱਧੇ ਕਨੈਕਸ਼ਨ ਨਾਲ ਸੇਵਾ ਪਛਾਣ ਦੀ ਜਾਂਚ ਅਤੇ ਲੋੜੀਂਦੀ ਪਹੁੰਚ ਨੀਤੀ ਦੋਵੇਂ ਰੱਖੋ। TLS ਚਾਲੂ ਕਰਨ ਨਾਲ ਐਨਕ੍ਰਿਪਟਿਡ ਕਨੈਕਸ਼ਨ ਉਪਲਬਧ ਹੁੰਦੇ ਹਨ; ਪਹੁੰਚ ਸੰਰਚਨਾ hostssl ਐਂਟਰੀਆਂ ਰਾਹੀਂ ਨਾ ਕਹੇ ਤਾਂ ਇਹ ਗ਼ੈਰ-ਐਨਕ੍ਰਿਪਟਿਡ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਰੱਦਦਾ।
ਇਹ ਫ਼ਰਕ ਟੈਂਪਲੇਟ ਵਿੱਚ ਨਹੀਂ, ਚੱਲ ਰਹੀ ਸੰਰਚਨਾ ਵਿੱਚ ਜਾਂਚਣ ਯੋਗ ਹੈ। TLS ਦੇਣ ਵਾਲਾ ਅਤੇ ਸਾਦਾ ਟੈਕਸਟ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਉਹ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੈ ਜੋ ਬਹੁਤੇ ਲੋਕ ਸਮਝਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਤੈਨਾਤ ਕੀਤਾ ਹੈ। ਪਹੁੰਚ ਨਿਯਮ ਪੜ੍ਹੋ ਅਤੇ ਵੇਖੋ ਕਿ ਕਿਹੜੀਆਂ ਐਂਟਰੀਆਂ ਅਸਲ ਵਿੱਚ ਇਸ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ। ਉਹੀ ਇੱਕ ਜਾਂਚ ਐਨਕ੍ਰਿਪਸ਼ਨ-ਯੋਗ ਸਰਵਰ ਨੂੰ ਸਿਰਫ਼-ਐਨਕ੍ਰਿਪਟਿਡ ਸਰਵਰ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ।
ਸਿਰਫ਼ ਕੰਮ ਲਈ ਲੋੜੀਂਦੇ ਅਧਿਕਾਰਾਂ ਵਾਲੀਆਂ ਭੂਮਿਕਾਵਾਂ ਵਰਤੋ, ਅਤੇ ਮਾਲਕੀ, ਵਿਰਾਸਤੀ ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਦਿੱਤੀਆਂ ਇਜਾਜ਼ਤਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। PostgreSQL ਅਧਿਕਾਰ ਮਾਡਲ ਡੇਟਾਬੇਸ ਵਸਤੂਆਂ ਲਈ ਅਧਿਕਾਰ ਦੀ ਸੀਮਾ ਹੈ।
VPN ਤੈਅ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਪਹਿਲਾਂ ਕਿਹੜੇ ਯੰਤਰ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਅਤੇ ਪਹੁੰਚ ਗੇਟਵੇ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਖੁੱਲ੍ਹੇ ਭਾਗ ਦੀ ਸੰਭਾਲ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਪ੍ਰਬੰਧਨ ਅਤੇ ਸਰੋਤ ਵਰਤੋਂ ਸੀਮਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹਟਾਉਂਦਾ।
ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਇੱਕ ਪ੍ਰਮਾਣ ਹੈ, ACL ਨਹੀਂ
ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਕਨੈਕਸ਼ਨ ਸਮੇਂ ਇੱਕ ਸ਼ਰਤ ਜੋੜ ਸਕਦਾ ਹੈ। clientcert ਸੈਟਿੰਗ ਭਰੋਸੇਯੋਗ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਸਖ਼ਤ ਮੋਡ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਮ ਅਤੇ ਡੇਟਾਬੇਸ ਵਰਤੋਂਕਾਰ ਵਿਚਕਾਰ ਸੰਬੰਧ ਦੀ ਮੰਗ ਕਰ ਸਕਦੀ ਹੈ।
ਇਹ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਪ੍ਰਮਾਣ ਹੈ। ਇਹ ਅਧਿਕਾਰ ਸੂਚੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਸਰਵਰ ਨੂੰ ਅਦਿੱਖ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਕਿਉਂਕਿ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਭਾਗ ਅਜੇ ਵੀ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਸੰਭਾਲਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਪਹੁੰਚ ਸੂਚੀ ਮੰਨਣ ਨਾਲ ਅਸਲ ਇਜਾਜ਼ਤਾਂ ਅਛੂਤੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਇਹ ਸਰਟੀਫਿਕੇਟ ਵੰਡ ਨੂੰ ਚੌੜਾ ਕਰਨ ਵੱਲ ਵੀ ਰੁਝਾਨ ਰੱਖਦਾ ਹੈ, ਜੋ ਅਗਲੀ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਧਿਕਾਰਾਂ ਵਾਲੀ ਭੂਮਿਕਾ ਨਾਲ ਜੁੜਿਆ ਮਜ਼ਬੂਤ ਸਰਟੀਫਿਕੇਟ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪ੍ਰਮਾਣਿਤ ਪ੍ਰਸ਼ਾਸਕ ਬਣਾਉਂਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਦਾ ਜਸ਼ਨ ਮਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਭੂਮਿਕਾ ਦੀ ਜਾਂਚ ਕਰੋ।
ਢੁੱਕਵਾਂ ਹੋਵੇ ਤਾਂ ਸੰਕੀਰਣ ਇੰਟਰਫ਼ੇਸ ਚੁਣੋ
ਖਰਚੇ ਦੇ ਦਾਅਵੇ ਲਈ, ਦਾਅਵਾ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ, ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਲਾਗੂ ਕਰਨ ਵਾਲਾ ਅਤੇ ਉਸ ਵਰਤੋਂਕਾਰ ਦਾ ਮਨਜ਼ੂਰ ਨਤੀਜਾ ਵਾਪਸ ਕਰਨ ਵਾਲਾ ਐਪਲੀਕੇਸ਼ਨ ਅੰਤ-ਬਿੰਦੂ ਆਮ SQL ਖਾਤੇ ਨਾਲੋਂ ਕਿਰਿਆ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਦਰਸਾਉਂਦਾ ਹੈ।
ਫਿਰ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੀ ਸੀਮਤ ਡੇਟਾਬੇਸ ਪਛਾਣ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਗਾਹਕ ਨੂੰ ਕਦੇ ਵੀ ਵਿਸ਼ੇਸ਼ਤਾ ਵਜੋਂ ਕਵੈਰੀ ਭਾਸ਼ਾ ਨਹੀਂ ਮਿਲਦੀ। ਇਹ ਛੋਟੀ ਸਤ੍ਹਾ ਹੈ ਜਿਸ ਵਿੱਚ ਗਲਤ ਹੋਣ ਦੇ ਘੱਟ ਰਾਹ ਹਨ।
ਇਹ ਡਿਜ਼ਾਈਨ ਵਿਕਲਪ ਹੈ, ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਆਪਣੇ ਆਪ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਹੈ। ਉਸ ਕੋਡ ਨੂੰ ਆਪਣੇ ਕਾਲਰਾਂ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨੀ, ਹਰ ਕਿਰਿਆ ਨੂੰ ਅਧਿਕਾਰਤ ਕਰਨਾ ਅਤੇ ਆਪਣੇ ਇਨਪੁਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਦੀਆਂ ਆਪਣੀਆਂ ਡੇਟਾਬੇਸ ਇਜਾਜ਼ਤਾਂ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ।
ਸਿੱਧਾ SQL ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਅਤੇ ਸਾਧਨਾਂ ਲਈ ਸਹੀ ਰਹਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਮਨਜ਼ੂਰ ਕੰਮ ਨੂੰ ਇਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਭੂਮਿਕਾਵਾਂ, ਨੈੱਟਵਰਕ ਦਾਇਰੇ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਸੀਮਾਵਾਂ ਨਾਲ ਬੰਨ੍ਹੋ, ਅਤੇ ਬਾਕੀ ਕਲਾਇੰਟ ਸੰਕੀਰਣ ਇੰਟਰਫ਼ੇਸ ਰੱਖਣ। ਦੋਵੇਂ ਆਬਾਦੀਆਂ ਨੂੰ ਇੱਕ ਭੂਮਿਕਾ ਵਿੱਚ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੋਂ ਬਹਿਸ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।