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

ਦੋ ਦਾਅਵੇ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਸੈਲਾਨੀ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

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

ਦੂਜਾ ਦਾਅਵਾ ਇੱਕ ਹਿੱਸੇ ਬਾਰੇ ਹੈ: ਗੇਟਵੇ, ਜਾਂ ਇਸ ਦੇ ਪਿੱਛੇ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ, ਕਿਸੇ ਹੋਰ ਦੇ ਨਿਯੰਤਰਣ ਵਿੱਚ ਹੈ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਧਾਰਨਾ ਤੋਂ ਸਵਾਲ ਇਸ ਤੋਂ ਬਦਲ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ URL ਦੀ ਆਗਿਆ ਹੈ, ਇਸ ਵੱਲ ਕਿ ਪ੍ਰਕਿਰਿਆ ਅਜੇ ਕਿਹੜੇ ਮੰਜ਼ਿਲਾਂ ਅਤੇ ਪਛਾਣਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ।

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

ਇੱਕ ਕੰਮ ਕੀਤੀ ਖਰਚ ਸੇਵਾ, ਅਤੇ ਉਹ ਜਿਨ੍ਹਾਂ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਹਾਰਦੀ ਹੈ

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

ਹੁਣ ਗੇਟਵੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸਮੂਹ ਵਿੱਚੋਂ ਹਟਾਓ। 10.60.4.10 ਦੀ ਪ੍ਰਕਿਰਿਆ ਹਮਲਾਵਰ ਦੀ ਹੋਣ 'ਤੇ ਉਹ ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ? ਸੈਲਾਨੀਆਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਵਾਲਾ URL ਫਿਲਟਰ ਗੇਟਵੇ ਹੋਸਟ ਵੱਲੋਂ ਡੇਟਾਬੇਸ ਸਬਨੈੱਟ ਵੱਲ ਖੋਲ੍ਹੇ ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।

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

ਹਰ ਧਿਰ ਕੋਲ ਅਸਲ ਵਿੱਚ ਜੋ ਅਧਿਕਾਰ ਹੈ, ਉਸ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ

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

ComponentAuthority it actually holdsCheck that proves the denialOwner of the check
Identity providerIssues assertions and session cookies, and holds no network path of its ownA request to the application URL without a session is redirected to the login pageIdentity team
Public gateway hostTCP reachability to whatever its routing table and egress rules permitAn egress rule drops 10.60.4.20:5432 and the probe reports the port filteredNetwork platform team
Application roleSQL privileges granted to expenses_app inside the expenses databaseA privilege query shows no ownership or create right on any other schemaApplication team
Database listenerAccepts connections only from the source ranges named in its host-based rulesA connection from an unlisted address is refused before authenticationDatabase administrator
Management pathAdministrative access reserved for patching, monitoring and recoveryA staff workstation cannot reach the administrative port or jump through itPlatform owner

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

ਇਹ ਵੰਡ ਦੋਹਰੀ ਗਿਣਤੀ ਵੀ ਰੋਕਦੀ ਹੈ। ਪੋਰਟ ਪਾਬੰਦੀ ਸਾਰਣੀ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਨਹੀਂ ਦਰਸਾ ਸਕਦੀ, ਅਤੇ ਡੇਟਾਬੇਸ ਭੂਮਿਕਾ ਕਿਸੇ ਹੋਸਟ ਨੂੰ ਅਸੰਬੰਧਿਤ ਸਬਨੈੱਟ ਵੱਲ ਸਾਕਟ ਖੋਲ੍ਹਣ ਤੋਂ ਨਹੀਂ ਰੋਕ ਸਕਦੀ।

ਗੇਟਵੇ ਕਿੱਥੋਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਇਹ ਦਾਅਵਾ ਕਰਨ ਦੀ ਬਜਾਏ ਗਿਣੋ

ਸੀਮਾ ਦਾ ਦਾਅਵਾ ਉਸ ਦੇ ਪਿੱਛੇ ਦੀ ਗਿਣਤੀ ਜਿੰਨਾ ਹੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ। ਗੇਟਵੇ ਹੋਸਟ 'ਤੇ ਤਿੰਨ ਹੁਕਮ ਰਸਤਾ ਚੋਣ, ਸਿੱਧੀ ਜਾਂਚ ਅਤੇ ਨਿੱਕਾਸ ਨੀਤੀ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ:

ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter output

ਆਉਟਪੁੱਟ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ। ਰਸਤਾ ਦੱਸਦਾ ਹੈ ਕਿ 10.60.4.20 ਉਸ ਹੋਸਟ ਤੋਂ ਹੀ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਜਾਂਚ ਦੱਸਦੀ ਹੈ ਕਿ ਸਰੋਤਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਨੀਤੀ ਪੈਕੇਟ ਰੋਕਦੀ ਹੈ ਜਾਂ ਉਸ ਦੇ ਰਸਤੇ ਵਿੱਚ ਕਦੇ ਕੁਝ ਸੀ ਹੀ ਨਹੀਂ।

ਐਪਲੀਕੇਸ਼ਨ ਹੋਸਟ ਤੋਂ ਗਿਣਤੀ ਦੁਹਰਾਓ। ਉੱਥੋਂ ਡੇਟਾਬੇਸ ਪਾਸਾ ਐਪਲੀਕੇਸ਼ਨ ਭੂਮਿਕਾ ਵਜੋਂ ਚਲਾਈ ਗਈ ਇੱਕ ਕਵੈਰੀ ਹੈ:

psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'

ਦੂਜੀ ਸਕੀਮਾ ਪੜ੍ਹ ਨਾ ਸਕਣ ਵਾਲੀ ਭੂਮਿਕਾ ਹੇਠ ਸਫਲ ਕਨੈਕਸ਼ਨ ਮਾਲਕ ਭੂਮਿਕਾ ਹੇਠ ਸਫਲ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਖਰਾ ਨਤੀਜਾ ਹੈ। ਸਿਰਫ਼ ਦੂਜਾ ਹੀ ਇੱਕ ਖੋਜ ਹੈ।

ਇਨਕਾਰ ਦਰਜ ਕਰੋ, ਫਿਰ ਸਮੀਖਿਆ ਨੂੰ ਤਾਰੀਖ ਦਿਓ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ