ਕੀ VPN ਲੌਗ ਬ੍ਰਾਊਜ਼ਿੰਗ ਇਤਿਹਾਸ ਦਿਖਾ ਸਕਦਾ ਹੈ? ਸਬੂਤ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ
ਇੱਕ ਸੈਸ਼ਨ ਲੌਗ, ਇੱਕ ਰੈਜ਼ੌਲਵਰ ਪੁੱਛਗਿੱਛ ਅਤੇ ਇੱਕ ਫਲੋ ਰਿਕਾਰਡ ਵੱਖ-ਵੱਖ ਗੱਲਾਂ ਸਾਬਤ ਕਰਦੇ ਹਨ। ਸਵਾਲ ਚੁਣੋ, ਪਛਾਣ ਅਤੇ ਸਮਾਂ ਜੋੜੋ, ਫਿਰ ਸਿਰਫ਼ ਉਹੀ ਦੱਸੋ ਜੋ ਦਿਖਿਆ।
ਦੋ ਆਡਿਟ ਸਵਾਲ ਇੱਕੋ ਜਿਹੇ ਸੁਣਾਈ ਦਿੰਦੇ ਹਨ ਪਰ ਵੱਖਰੀ ਕਿਸਮ ਦੇ ਸਬੂਤ ਮੰਗਦੇ ਹਨ। ਇਸ ਪਤੇ ਨਾਲ ਕਿਹੜੇ ਸੈਸ਼ਨ ਨੇ ਸੰਪਰਕ ਕੀਤਾ, ਇਹ ਕਨੈਕਸ਼ਨ ਅਤੇ ਫਲੋ ਰਿਕਾਰਡਾਂ ਤੋਂ ਦੱਸਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਪੰਨਾ ਕਿਹੜੇ ਵਿਅਕਤੀ ਨੇ ਖੋਲ੍ਹਿਆ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ, ਘੱਟੋ-ਘੱਟ ਉਨ੍ਹਾਂ ਰਿਕਾਰਡਾਂ ਤੋਂ ਤਾਂ ਨਹੀਂ। ਸਵਾਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸੰਗ੍ਰਾਹਕ ਚੁਣਨਾ ਇਹ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਟੀਮ ਅੰਤ ਵਿੱਚ ਹੋਸਟਨਾਮ ਨੂੰ ਬ੍ਰਾਊਜ਼ਿੰਗ ਇਤਿਹਾਸ ਵਜੋਂ ਪੇਸ਼ ਕਰਦੀ ਹੈ।
ਉਸ ਘਟਨਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਆਡਿਟ ਨੇ ਸਾਬਤ ਕਰਨੀ ਹੈ
ਸਵਾਲ ਨੂੰ ਵਿਸ਼ਾ, ਕਿਰਿਆ ਅਤੇ ਸਮੇਂ ਵਾਲੇ ਵਾਕ ਵਜੋਂ ਲਿਖੋ। ਸਿਰਫ਼ ਇਹੀ ਅਨੁਸ਼ਾਸਨ ਸੈਸ਼ਨ ਰਿਕਾਰਡ ਅਤੇ ਪੰਨਾ ਦੇਖਣ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਉਜਾਗਰ ਕਰਦਾ ਹੈ। ਸੈਸ਼ਨ ਲੌਗ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਪਛਾਣ, ਕਿਸੇ ਅੰਤਰਾਲ ਲਈ, ਦਰਜ ਨੀਤੀ ਹੇਠ ਦਿੱਤੇ ਪਤੇ ਨਾਲ ਸਵੀਕਾਰ ਕੀਤੀ ਗਈ, ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕਿਸ ਨੇ ਕਿਹੜਾ ਪੰਨਾ ਪੜ੍ਹਿਆ, ਕਿਉਂਕਿ ਇਸ ਨੇ ਬੇਨਤੀ ਕਦੇ ਨਹੀਂ ਦੇਖੀ।
ਸੰਗ੍ਰਹਿ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰੀਖਣ ਨੂੰ ਨਾਮ ਦਿਓ। ਕਿਸੇ ਦੇਖੀ ਗਈ ਸਾਈਟ ਦੇ ਨਾਮ ਵਾਲਾ ਖੇਤਰ ਜੋ ਅਸਲ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਨਾਮ ਸੰਭਾਲਦਾ ਹੈ, ਭਵਿੱਖ ਦੀ ਗਲਤੀ ਹੈ, ਸੁਵਿਧਾ ਨਹੀਂ। ਖੇਤਰਾਂ ਦੇ ਨਾਮ ਉਨ੍ਹਾਂ ਚੁਣਨ ਵਾਲਿਆਂ ਤੋਂ ਵੱਧ ਚਿਰ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਸਿੱਟੇ ਦੀ ਥਾਂ ਸਬੂਤ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੇ ਨਾਮ ਚੁਣੋ।
ਹਰੇਕ ਰਿਕਾਰਡ ਕੀ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਲਗਭਗ ਹਰ ਆਡਿਟ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਚਾਰ ਕਿਸਮਾਂ ਦੇ ਰਿਕਾਰਡ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਹਰੇਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਰਿਪੋਰਟ ਵਿੱਚ ਵੀ ਅਤੇ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਹੀ ਇੱਕ ਬਚਾਉਣਯੋਗ ਖੋਜ ਸ਼ਰਮਿੰਦਗੀ ਬਣ ਜਾਂਦੀ ਹੈ।
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
ਆਖਰੀ ਕਾਲਮ ਨੂੰ ਵਿਚਕਾਰਲੇ ਜਿੰਨੇ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹੋ। ਫਲੋ ਰਿਕਾਰਡ ਪਤਿਆਂ ਅਤੇ ਪੋਰਟਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਪਤੇ ਦੀ ਉਲਟ ਖੋਜ ਉਹ ਨਾਮ ਮੁੜ ਨਹੀਂ ਬਣਾਉਂਦੀ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਵਰਤਿਆ, ਕਿਉਂਕਿ ਇੱਕ ਪਤੇ ਉੱਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਅਸੰਬੰਧਿਤ ਸਾਈਟਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਰੈਜ਼ੌਲਵਰ ਪੁੱਛਗਿੱਛ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਸਵਾਲ ਪੁੱਛਿਆ ਗਿਆ, ਇਹ ਨਹੀਂ ਕਿ ਪੰਨਾ ਦਿਖਾਇਆ ਗਿਆ। TLS ਗੱਲਬਾਤ ਦੌਰਾਨ ਦਿਖਣ ਵਾਲਾ ਹੋਸਟਨਾਮ ਵੀ ਐਨਕ੍ਰਿਪਟ ਬੇਨਤੀ ਮਾਰਗ ਨਹੀਂ ਹੈ।
ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਸੱਚਾ ਨਿਰੀਖਣ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਹ ਨਿਰੀਖਣ ਨਹੀਂ ਜੋ ਲੋਕ ਮੰਨਦੇ ਹਨ। ਆਪਣੇ ਐਨਕ੍ਰਿਪਟ ਰੈਜ਼ੌਲਵਰ ਉੱਤੇ ਅੜਿਆ ਬ੍ਰਾਊਜ਼ਰ ਨਿਗਰਾਨੀ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਉਹ ਮੁੜ ਨਹੀਂ ਲੱਭ ਸਕਦਾ ਜੋ ਲੌਗਿੰਗ ਨੇ ਕਦੇ ਨਹੀਂ ਦੇਖਿਆ। ਇਹ ਫ਼ਰਕ ਰਿਪੋਰਟ ਵਿੱਚ ਫੁਟਨੋਟ ਨਹੀਂ ਬਲਕਿ ਸਪਸ਼ਟ ਸੀਮਾ ਵਜੋਂ ਦਰਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅਨੁਮਾਨਿਤ ਖੋਜਾਂ ਅਤੇ ਕੈਸ਼ ਵਿੱਚਲੇ ਜਵਾਬ
ਬ੍ਰਾਊਜ਼ਰ ਨਾਮ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਕਰ ਲੈਂਦੇ ਹਨ, ਕਦੇ-ਕਦੇ ਕੁਝ ਵੀ ਲੋਡ ਕੀਤੇ ਬਿਨਾਂ। ਉਹ ਕੈਸ਼ ਤੋਂ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਦੇਖੇ ਜਾ ਰਹੇ ਰੈਜ਼ੌਲਵਰ ਨੂੰ ਨਵੀਂ ਪੁੱਛਗਿੱਛ ਨਹੀਂ ਭੇਜਦੇ, ਜਿਸ ਦਾ ਮਤਲਬ ਹੈ ਪੁੱਛਗਿੱਛ ਦਾ ਨਾ ਹੋਣਾ ਫੇਰੀ ਦਾ ਨਾ ਹੋਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਦੋਵੇਂ ਵਿਵਹਾਰ DNS ਲੌਗ ਅਤੇ ਬ੍ਰਾਊਜ਼ਿੰਗ ਇਤਿਹਾਸ ਵਿਚਕਾਰਲੇ ਸਿੱਧੇ ਸਮੀਕਰਨ ਨੂੰ ਤੋੜਦੇ ਹਨ।
DNS over HTTPS ਦੂਜੀ ਸੀਮਾ ਜੋੜਦਾ ਹੈ: ਆਪਣੇ ਰੈਜ਼ੌਲਵਰ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂ ਮਹਿਮਾਨ ਐਪਲੀਕੇਸ਼ਨ ਸੰਸਥਾ ਦੇ ਲੌਗਰ ਨੂੰ ਕੁਝ ਵੀ ਨਹੀਂ ਪੁੱਛਦਾ। ਸਹੀ ਲੈਣ-ਦੇਣ ਸਿਰਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਆਪਣੀਆਂ ਘਟਨਾਵਾਂ ਤੋਂ ਜਾਂ ਅਜਿਹੇ ਪ੍ਰੌਕਸੀ ਤੋਂ ਆਉਂਦੇ ਹਨ ਜਿਸ ਦੀ ਲੌਗਿੰਗ ਦਾ ਤੁਸੀਂ ਸਪਸ਼ਟ ਸਮਰਥਨ ਕਰਦੇ ਹੋ। ਸਾਧਾਰਨ HTTPS CONNECT ਸੁਰੰਗ ਪ੍ਰੌਕਸੀ ਨੂੰ ਅੰਦਰਲੇ ਪੰਨਾ ਮਾਰਗਾਂ ਦੀ ਕੋਈ ਝਲਕ ਨਹੀਂ ਦਿੰਦੀ। ਨੈੱਟਵਰਕ ਦਾ ਮਾਲਕ ਹੋਣਾ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਭਰੋਸਾ ਮਾਡਲ ਚੁੱਪ-ਚਾਪ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ।
ਪਤਾ ਸੈਸ਼ਨ ਦਾ ਹੁੰਦਾ ਹੈ, ਵਿਅਕਤੀ ਦਾ ਨਹੀਂ
ਸੁਰੰਗ ਰੇਂਜ ਦਾ ਪਤਾ ਲੈ ਕੇ ਆਉਣ ਵਾਲਾ ਫਲੋ ਰਿਕਾਰਡ ਜਵਾਬ ਨਹੀਂ ਬਲਕਿ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ। ਉਸ ਪਤੇ ਅਤੇ ਸਮੇਂ ਨੂੰ ਉਸ ਵੇਲੇ ਸਰਗਰਮ ਸੈਸ਼ਨ ਅਸਾਈਨਮੈਂਟ ਨਾਲ ਜੋੜੋ, ਕਿਉਂਕਿ ਉਹੀ ਪਤਾ ਇੱਕ ਘੰਟੇ ਬਾਅਦ ਕਿਸੇ ਹੋਰ ਸੈਸ਼ਨ ਨੂੰ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਥਿਰ ਪਤਾ ਉਹ ਸੰਬੰਧ ਬਣਾਈ ਰੱਖਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ, ਇਕੋ-ਇੱਕ ਨਹੀਂ।
ਜਿੱਥੇ ਅਨੁਵਾਦ ਦਾ ਕਦਮ ਸੈਂਸਰ ਤੋਂ ਉੱਪਰ ਕਈ ਡਿਵਾਈਸਾਂ ਨੂੰ ਇੱਕ ਸਰੋਤ ਪਤੇ ਵਿੱਚ ਸਮੇਟਦਾ ਹੈ, ਉੱਥੇ ਜੋੜ ਸਿਰਫ਼ ਸਾਂਝੇ ਗੇਟਵੇ ਸੈਸ਼ਨ ਦਾ ਨਾਮ ਦੱਸ ਸਕਦਾ ਹੈ। ਸਾਂਝਾ ਖਾਤਾ ਜਾਂ ਕਈ ਲੋਕਾਂ ਵੱਲੋਂ ਵਰਤਿਆ ਸਰਟੀਫਿਕੇਟ ਨੈੱਟਵਰਕ ਡੇਟਾ ਕਿੰਨਾ ਵੀ ਪੂਰਾ ਦਿਸੇ, ਗੁਣਾ ਦੀ ਸ਼ੁੱਧਤਾ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਰਿਪੋਰਟ ਵਿੱਚ ਬਾਅਦ ਦੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨਹੀਂ ਬਲਕਿ ਸੀਮਾਵਾਂ ਵਜੋਂ ਰੱਖੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।
ਸਮਾਂ ਖੇਤਰ, ਘੜੀ ਦਾ ਸਰੋਤ, ਨਿਰੀਖਣ ਬਿੰਦੂ ਅਤੇ ਵਿਚਕਾਰਲੀ ਹਰ ਅਨੁਵਾਦ ਸੀਮਾ ਦਰਜ ਕਰੋ। ਗੈਰ-ਹਾਜ਼ਰੀ ਨੂੰ ਵੀ ਹਾਜ਼ਰੀ ਜਿੰਨੀ ਸੰਭਾਲ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਰਿਕਾਰਡ ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ ਫਲੋ ਐਂਟਰੀ ਦਾ ਮਿਆਦ ਖਤਮ ਹੋਣਾ, ਸੈਂਸਰ ਦਾ ਪੈਕਟ ਕਦੇ ਨਾ ਦੇਖਣਾ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗ ਦਾ ਬੰਦ ਹੋਣਾ ਹੋ ਸਕਦਾ ਹੈ।
ਦੱਸੇ ਮਕਸਦ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ ਪਾਈਪਲਾਈਨ ਸਾਬਤ ਕਰੋ
ਸਵਾਲ ਪੱਕਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੇ ਖੇਤਰ ਲੋੜੀਂਦੇ ਹਨ, ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਿੰਨਾ ਚਿਰ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ। ਸਟੋਰੇਜ ਸਸਤਾ ਹੈ ਇਸ ਲਈ ਵੱਧ ਇਕੱਠਾ ਕਰਨਾ ਜਾਂਚ ਤੋਂ ਵੱਧ ਚਿਰ ਰਹਿਣ ਵਾਲੀ ਜ਼ਿੰਮੇਵਾਰੀ ਬਣਾਉਂਦਾ ਹੈ। RFC 6973 ਵਿੱਚਲਾ ਪਰਦੇਦਾਰੀ ਮਾਡਲ ਸਹਿ-ਸੰਬੰਧ, ਗਲਤ ਗੁਣਾ ਅਤੇ ਗੈਰ-ਜ਼ਰੂਰੀ ਸੰਗ੍ਰਹਿ ਨੂੰ ਬਾਅਦ ਦੀ ਸੋਚ ਨਹੀਂ ਬਲਕਿ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੱਸਿਆ ਮੰਨਦਾ ਹੈ।
ਮੈਪਿੰਗ ਅਤੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਇੱਕੋ ਵਸਤੂ ਵਜੋਂ ਸੰਭਾਲੋ, ਕਿਉਂਕਿ ਹਰੇਕ ਇਕੱਲਾ ਜੋੜੀ ਨਾਲੋਂ ਕਾਫ਼ੀ ਘੱਟ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦਾ ਹੈ। ਫਿਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਉਸ ਗਤੀਵਿਧੀ ਵਿਰੁੱਧ ਪਰਖੋ ਜੋ ਪੈਦਾ ਕਰਨ ਦੀ ਤੁਹਾਨੂੰ ਇਜਾਜ਼ਤ ਹੈ ਅਤੇ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਮਝਦੇ ਹੋ, ਰਿਪੋਰਟ ਜਿਸ ਸਭ ਤੋਂ ਛੋਟੀ ਪੁੱਛਗਿੱਛ ਉੱਤੇ ਨਿਰਭਰ ਕਰੇਗੀ ਉਹੀ ਵਰਤ ਕੇ। ਜਾਣੀ-ਪਛਾਣੀ ਘਟਨਾ ਦੁਬਾਰਾ ਪੈਦਾ ਨਾ ਕਰ ਸਕਣ ਵਾਲੀ ਪਾਈਪਲਾਈਨ ਅਣਜਾਣ ਘਟਨਾ ਵੀ ਦੁਬਾਰਾ ਪੈਦਾ ਨਹੀਂ ਕਰੇਗੀ। ਸਬੂਤ ਜਿਸ ਘਟਨਾ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਉਹੀ ਘਟਨਾ ਸਬੂਤ ਦੇ ਦਿੱਤੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੱਸੋ, ਅਤੇ ਵੱਡਾ ਸਿੱਟਾ ਪਾਠਕ ਆਪ ਹੀ ਕੱਢਣ ਦਿਓ।
ਸਿੱਟੇ ਦੇ ਕੋਲ ਸੀਮਾਵਾਂ ਲਿਖੋ: ਕੀ ਜੋੜਿਆ ਗਿਆ, ਕੀ ਅਨੁਵਾਦ ਹੋਇਆ, ਅਤੇ ਕਿਹੜਾ ਲੌਗ ਚੁੱਪ ਰਿਹਾ। ਆਪਣੀਆਂ ਸੀਮਾਵਾਂ ਦੱਸਣ ਵਾਲਾ ਸਿੱਟਾ ਉਹ ਸਮੀਖਿਆ ਸਹਿ ਲੈਂਦਾ ਹੈ ਜੋ ਭਰੋਸੇਵਾਨ ਸਾਰ ਸਹਿ ਨਹੀਂ ਸਕਦਾ। ਸਬੂਤ ਅਤੇ ਸਬੂਤ ਬਾਰੇ ਕਹਾਣੀ ਵਿਚਕਾਰ ਇਹੀ ਫ਼ਰਕ ਹੈ।