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 ಲಾಗ್ ಮತ್ತು ಬ್ರೌಸಿಂಗ್ ಇತಿಹಾಸದ ನಡುವಿನ ಸರಳ ಸಮೀಕರಣವನ್ನು ಮುರಿಯುತ್ತವೆ.
HTTPS ಮೇಲಿನ DNS ಎರಡನೇ ಗಡಿಯನ್ನು ಸೇರಿಸುತ್ತದೆ: ತನ್ನದೇ ರಿಜ್ಸಾಲ್ವರ್ ಇರುವ ಬ್ರೌಸರ್ ಅಥವಾ ಅತಿಥಿ ಅಪ್ಲಿಕೇಶನ್ ಸಂಸ್ಥೆಯ ಲಾಗರ್‌ಗೆ ಏನನ್ನೂ ಕೇಳುವುದಿಲ್ಲ. ನಿಖರ ವಹಿವಾಟುಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಘಟನೆಗಳಿಂದ ಅಥವಾ ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ಬೆಂಬಲಿಸುವ ಲಾಗಿಂಗ್ ಇರುವ ಪ್ರಾಕ್ಸಿಯಿಂದ ಮಾತ್ರ ಬರುತ್ತವೆ. ಸಾಮಾನ್ಯ HTTPS CONNECT ಸುರಂಗವು ಪ್ರಾಕ್ಸಿಗೆ ಅದರೊಳಗಿನ ಪುಟ ಮಾರ್ಗಗಳ ಯಾವುದೇ ನೋಟವನ್ನು ಬಿಡುವುದಿಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ಹೊಂದಿರುವುದು ಅಪ್ಲಿಕೇಶನ್‌ನ ನಂಬಿಕೆ ಮಾದರಿಯನ್ನು ಮೌನವಾಗಿ ಬದಲಿಸುವ ಅನುಮತಿಯಲ್ಲ.
ವಿಳಾಸವು ಸೆಷನ್‌ನದು, ವ್ಯಕ್ತಿಯದಲ್ಲ
ಸುರಂಗ ಶ್ರೇಣಿಯ ವಿಳಾಸವನ್ನು ಹೊತ್ತ ಹರಿವಿನ ದಾಖಲೆ ಉತ್ತರವಲ್ಲ, ಆರಂಭಿಕ ಬಿಂದು. ಆ ವಿಳಾಸ ಮತ್ತು ಸಮಯ ಚಿಹ್ನೆಯನ್ನು ಆ ಕ್ಷಣದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿದ್ದ ಸೆಷನ್ ಹಂಚಿಕೆಗೆ ಜೋಡಿಸಿ, ಏಕೆಂದರೆ ಆ ವಿಳಾಸವು ಒಂದು ಗಂಟೆಯ ನಂತರ ಬೇರೆ ಸೆಷನ್‌ಗೆ ಹಂಚಲ್ಪಡಬಹುದು. ಸ್ಥಿರ ವಿಳಾಸೀಕರಣ ಆ ಸಂಬಂಧವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಒಂದು ದಾರಿ, ಏಕೈಕ ದಾರಿಯಲ್ಲ.
ಸೆನ್ಸರ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಅನುವಾದ ಹಂತವು ಹಲವು ಸಾಧನಗಳನ್ನು ಒಂದೇ ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಸೇರಿಸಿದಾಗ, ಜೋಡಣೆ ಹಂಚಿದ ಗೇಟ್‌ವೇ ಸೆಷನ್ ಅನ್ನು ಮಾತ್ರ ಹೆಸರಿಸಬಲ್ಲದು. ಹಂಚಿದ ಖಾತೆ ಅಥವಾ ಹಲವರು ಬಳಸುವ ಪ್ರಮಾಣಪತ್ರವು ನೆಟ್‌ವರ್ಕ್ ಡೇಟಾ ಎಷ್ಟೇ ಪೂರ್ಣವಾಗಿ ಕಂಡರೂ ಆರೋಪಣೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಎರಡೂ ವರದಿಯಲ್ಲಿ ನಂತರದ ಎಚ್ಚರಿಕೆಯಲ್ಲ, ಮಿತಿಯಾಗಿ ಇರಬೇಕು.
ಸಮಯ ವಲಯ, ಗಡಿಯಾರದ ಮೂಲ, ವೀಕ್ಷಣಾ ಬಿಂದು ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಪ್ರತಿ ಅನುವಾದ ಗಡಿಯನ್ನು ದಾಖಲಿಸಿ. ಅನುಪಸ್ಥಿತಿ ಉಪಸ್ಥಿತಿಯಷ್ಟೇ ಕಾಳಜಿಗೆ ಅರ್ಹ, ಏಕೆಂದರೆ ಕಾಣೆಯಾದ ದಾಖಲೆ ಎಂದರೆ ಹರಿವಿನ ನಮೂದಿನ ಅವಧಿ ಮುಗಿದಿರಬಹುದು, ಸೆನ್ಸರ್ ಪ್ಯಾಕೆಟ್ ಎಂದೂ ನೋಡಿರಲಿಲ್ಲ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್ ಆಫ್ ಆಗಿತ್ತು.
ಘೋಷಿತ ಉದ್ದೇಶಕ್ಕಾಗಿ ವಿನ್ಯಾಸ ಮಾಡಿ, ನಂತರ ಪೈಪ್‌ಲೈನ್ ಸಾಬೀತುಪಡಿಸಿ
ಪ್ರಶ್ನೆ ನಿಶ್ಚಿತವಾದ ನಂತರ, ಯಾವ ಕ್ಷೇತ್ರಗಳು ಬೇಕು, ಯಾರು ಅವನ್ನು ಓದಬಹುದು ಮತ್ತು ಎಷ್ಟು ಕಾಲ ಇಡಲಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಸಂಗ್ರಹಣೆ ಅಗ್ಗವಾಗಿದೆ ಎಂದು ಹೆಚ್ಚು ಸಂಗ್ರಹಿಸುವುದು ತನಿಖೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುವ ಹೊಣೆಗಾರಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. RFC 6973 ನಲ್ಲಿನ ಗೋಪ್ಯತೆ ಮಾದರಿಯು ಪರಸ್ಪರ ಸಂಬಂಧ, ತಪ್ಪು ಆರೋಪಣೆ ಮತ್ತು ಅನಗತ್ಯ ಸಂಗ್ರಹವನ್ನು ನಂತರದ ಯೋಚನೆಗಳಲ್ಲ, ವಿನ್ಯಾಸದ ಸಮಸ್ಯೆಗಳೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ.
ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ದಾಖಲೆಗಳನ್ನು ಒಂದೇ ವಸ್ತುವಾಗಿ ರಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಒಂಟಿಯಾಗಿ ಜೋಡಿಗಿಂತ ಬಹಳ ಕಡಿಮೆ ಸೂಕ್ಷ್ಮ. ನಂತರ ವಿನ್ಯಾಸವನ್ನು ನೀವು ಉತ್ಪಾದಿಸಲು ಅನುಮತಿ ಇರುವ ಮತ್ತು ಈಗಾಗಲೇ ಅರ್ಥಮಾಡಿಕೊಂಡಿರುವ ಚಟುವಟಿಕೆಯ ವಿರುದ್ಧ, ವರದಿ ಅವಲಂಬಿಸುವ ಅತ್ಯಂತ ಚಿಕ್ಕ ಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಿ ಮೌಲ್ಯೀಕರಿಸಿ. ತಿಳಿದ ಘಟನೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲಾಗದ ಪೈಪ್‌ಲೈನ್ ಅಜ್ಞಾತ ಘಟನೆಯನ್ನೂ ಪುನರುತ್ಪಾದಿಸುವುದಿಲ್ಲ. ಸಾಕ್ಷ್ಯಗಳು ಬೆಂಬಲಿಸುವ ಘಟನೆಯನ್ನು ಸಾಕ್ಷ್ಯಗಳು ಅನುಮತಿಸುವ ಪದಗಳಲ್ಲಿ ವರದಿ ಮಾಡಿ, ಮತ್ತು ದೊಡ್ಡ ತೀರ್ಮಾನಕ್ಕೆ ತಲುಪುವುದನ್ನು ಓದುಗರಿಗೇ ಬಿಡಿ.
ತೀರ್ಮಾನದ ಪಕ್ಕದಲ್ಲಿ ಮಿತಿಗಳನ್ನು ಬರೆಯಿರಿ: ಏನು ಜೋಡಿಸಲಾಯಿತು, ಏನು ಅನುವಾದವಾಯಿತು ಮತ್ತು ಯಾವ ಲಾಗ್ ಮೌನವಾಗಿತ್ತು. ತನ್ನ ಮಿತಿಗಳನ್ನು ಘೋಷಿಸುವ ಸಂಶೋಧನೆ ಆತ್ಮವಿಶ್ವಾಸದ ಸಾರಾಂಶವು ದಾಟಲಾಗದ ಪರಿಶೀಲನೆಯನ್ನು ದಾಟುತ್ತದೆ. ಸಾಕ್ಷ್ಯ ಮತ್ತು ಸಾಕ್ಷ್ಯದ ಕಥೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಅದೇ.