ઉપકરણના લોગ દૂરસ્થ સંગ્રાહકને સુરક્ષિત રીતે કેવી રીતે મોકલવા

ઉપકરણ લોગ ઉત્સર્જિત કરી શકે છે, સંગ્રાહક ઇન્ટરનેટની બીજી બાજુ બેસે છે, અને દરેક પૂછે છે તે પહેલો પ્રશ્ન એ છે કે કયો ટનલ બનાવવો। આ રૂપરેખા ખોટી જગ્યાએથી શરૂ થાય છે। પરિવહન નક્કી કરે છે ઉપકરણ જે ફોર્મેટ બનાવી શકે, સંગ્રાહક જે પ્રમાણીકરણ સ્વીકારશે, અને લિંક તૂટે ત્યારે “ડિલિવર થયું” નો અર્થ શું હોવો જોઈએ। એ ત્રણ જવાબ લખી લો, અને પરિવહન સામાન્ય રીતે પોતાને પસંદ કરી લે છે।

ઉપકરણ જે ઉત્સર્જિત કરી શકે તેનાથી શરૂ કરો

વ્યવહારમાં માત્ર ત્રણ આકાર છે। UDP અથવા TCP પર વ્યક્તિગત syslog ઘટનાઓ, ઉત્પાદનમાં બનેલું પ્રમાણીકૃત HTTPS અપલોડ, અથવા ડિસ્ક પર લખાયેલી સંપૂર્ણ ફાઇલો જે ખસેડવી પડે। જે ફાયરવોલ ફક્ત UDP syslog મોકલી શકે છે તે ટનલ ઉમેરવાથી TLS મોકલનાર બનશે નહીં; તે હજી પણ અપ્રમાણિત ડેટાગ્રામ મોકલશે, હવે એન્ક્રિપ્ટેડ પરબિડીયામાં।

તેથી પહેલા મોકલનારની યાદી બનાવો: પ્રોટોકોલ, TLS આધાર અને કઈ TLS લાઇબ્રેરી, તે સંગ્રાહકનું પ્રમાણપત્ર ચકાસી શકે છે કે નહીં, ગ્રાહક પ્રમાણપત્ર રજૂ કરી શકે છે કે નહીં, અને મોકલવાનું બફર રીબૂટ ટકી રહે છે કે નહીં। ઉપકરણ જે કરી શકતું નથી તે પાથમાં બીજું કંઈક કરવું પડશે, અને તે બીજું કંઈક તમારી રચનાનો ભાગ બની જાય છે।

TLS syslog: બંને છેડા બોલે ત્યારે સૌથી ટૂંકો રસ્તો

જો ઉપકરણ TLS પર syslog ને સમર્થન આપે છે અને સંગ્રાહક તેને સમાપ્ત કરે છે, તો તેનો ઉપયોગ કરો અને થોભો। એપ્લિકેશન પ્રોટોકોલ પોતાને રક્ષે છે, સંગ્રાહક મોકલનારનું પ્રમાણીકરણ કરે છે, અને હવે તમારી પાસે જેની ઉપલબ્ધતા છે એવું કોઈ વધારાનું પગલું નથી। છટકું એ છે કે “TLS syslog” વિશાળ અમલીકરણોને આવરી લે છે, અને સુરક્ષિત syslog માટેના વર્તમાન માર્ગદર્શન જૂનાં ટ્યુટોરિયલ્સની સાઇફર યાદીઓથી આગળ વધ્યાં છે, અને એટલે જ કામ કરતું ફોરવર્ડર લાઇબ્રેરી અપગ્રેડ પછી તૂટી જાય છે।

rsyslog માં ફક્ત પરિવહન મોડ્યુલનું નામ જ કહે છે કે તમે કયા યુગમાં છો: lmnsd_gtls GnuTLS ને લપેટે છે, જ્યારે lmnsd_ossl OpenSSL ને લપેટે છે અને વર્તમાન 8.x પેકેજો એ જ આપે છે। પ્રમાણપત્ર ચકાસણી સાથેની ફોરવર્ડ ક્રિયા લગભગ આવી દેખાય છે, અને ચોક્કસ પરિમાણ નામો તમારી સ્થાપિત આવૃત્તિ સામે ચકાસવા યોગ્ય છે:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

મોકલનારને ડિબગ કરતા પહેલા અંતિમ બિંદુ ચકાસો। openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error કાં તો માન્ય શૃંખલા સાથે હેન્ડશેક પૂર્ણ કરે છે, અથવા કઈ ચકાસણી નિષ્ફળ ગઈ તે ચોક્કસ કહે છે। ઉપકરણથી પરીક્ષણ કરો, તમારા લેપટોપથી નહીં, કારણ કે ઉપકરણનું ટ્રસ્ટ સ્ટોર જ મહત્વનું છે।

SFTP: ફાઇલો માટે સારું, પ્રવાહો માટે ખોટું

ફાઇલ-આધારિત ડિલિવરી એવાં ઉપકરણો માટે યોગ્ય છે જે ફરતા લોગ લખે છે અને બીજું કંઈ નહીં। SSH-આધારિત ટ્રાન્સફર તમને હોસ્ટ કી, દરેક ખાતાની કી અને ઓડિટ કરી શકાય એવી ફાઇલસિસ્ટમ આપે છે, જે TLS બિલકુલ કરી શકતા ન હોય એવા ઉપકરણ માટે વાજબી વિશ્વાસકથા છે। ઘટના-પ્રવાહો માટે તે નબળી પસંદગી છે, જ્યાં “ફાઇલ દર કલાકે લખાય છે” એટલે કે વિક્ષેપ તમને ચાલુ કલાકની પૂંછડી ગુમાવે છે।

હોસ્ટ ચકાસણી ચાલુ રાખો। પ્રોમ્પ્ટ ટાળવા માટે તેને બંધ કરતું બેચ કૉલ પરિવહન પાસેનું એકમાત્ર પ્રમાણીકરણ નષ્ટ કરે છે:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

જમાવટ દરમિયાન ખાતાના known_hosts માં હોસ્ટ કી પિન કરો, ખાતાને લક્ષ્ય ડિરેક્ટરી સુધી મર્યાદિત કરો, અને chroot સાથે internal-sftp સબસિસ્ટમ પસંદ કરો। પુનઃમોકલવાની વાર્તા પણ યોજો: જો આંશિક નિષ્ફળતા પછી ફાઇલ ફરી મોકલાય, તો સંગ્રાહકે નકલને નવી ફાઇલથી અલગ પાડવી જોઈએ, સામાન્ય રીતે નામ અને ચેકસમ દ્વારા, આગમન સમયથી નહીં।

જ્યારે સ્થાનિક ગેટવે અથવા ટનલ પ્રામાણિક જવાબ હોય

કેટલાંક ઉપકરણો ફક્ત એવા ફોર્મેટમાં બોલી શકે છે જે કોઈ ખુલ્લું ન કરવા માંગે। તે સ્થિતિમાં ઉપકરણના પોતાના નેટવર્ક પરનું અધિકૃત સંગ્રાહક મૂળ ફોર્મેટ મેળવે છે અને તેને TLS દ્વારા આગળ મોકલે છે। તે કાયદેસર રચના છે, પણ તે શું ખરીદે છે તે સ્પષ્ટ કરો: ગેટવે પર શરૂ થતું એન્ક્રિપ્શન ઉપકરણ અને ગેટવે વચ્ચેના ભાગને પાછળથી રક્ષતું નથી, તેથી તે પગલાને હજી પોતાની વિશ્વાસ-સીમા અને પ્રવેશ નિયંત્રણની જરૂર છે।

રૂટ કરેલો સાઇટ અથવા ઉપકરણ ટનલ સૌથી ભારે વિકલ્પ છે અને ત્યારે યોગ્ય છે જ્યારે સંગ્રાહકે ખાનગી સરનામું રાખવું પડે અને ફક્ત લોગ નહીં, અનેક સેવાઓ વહન કરવી પડે। તે સરનામા આયોજન, પ્રવેશ નિયમો, પરત માર્ગો અને ટનલ અંતિમ બિંદુનું જીવનચક્ર લાવે છે। તે આંતરિક પ્રોટોકોલ સુધારતું નથી: IPsec ટનલની અંદર UDP syslog હજી પણ ડિલિવરી સ્વીકૃતિ વગરની ડેટાગ્રામ સેવા છે।

તમે શું પસંદ કરો, સંગ્રાહકનું અધિકૃતીકરણ પરિવહન કરતાં સાંકડું રાખો। ટનલની ઓળખ અંતિમ બિંદુની છે, અને તે સંદેશમાં આપેલું હોસ્ટનેઝ ક્ષેત્ર કયા નીચલા ઉપકરણે બનાવ્યું તે વિશે કંઈ કહેતું નથી।

મોકલતા પહેલા ડિલિવરી કરાર લખો

એન્ક્રિપ્શન, પ્રમાણીકરણ અને જાળવણી જુદા જુદા પ્રશ્નોના જવાબ આપે છે, અને કતાર એ જાળવણી નીતિ નથી। પહેલો લોગ ઉપકરણ છોડે તે પહેલા નક્કી કરો કે આ સંગ્રાહક પર સ્વીકૃતિનો ખરો અર્થ શું છે: તાર પર મળ્યું, પ્રક્રિયા માટે સ્વીકારાયું, અથવા સંગ્રહમાં ટકાઉ રીતે લખાયું। એ ત્રણ જુદી ગેરંટી છે અને ફક્ત છેલ્લી જ સંગ્રાહકના રીસ્ટાર્ટ પછી ટકે છે।

પછી કાર્યાત્મક પ્રશ્નોના લેખિત જવાબ આપો। ન મોકલાયેલી ઘટનાઓ ક્યાં રાહ જુએ છે, અને તે બફર વીજ કાપ સહન કરે છે? ભરાઈ જાય ત્યારે શું થાય છે, અને કોને જાણ કરાય છે? પુનઃપ્રયાસો કેવી રીતે મર્યાદિત છે, અને નકલો કેવી રીતે ઓળખાય છે? કયું ક્ષેત્ર મોકલનારની ઓળખ સાબિત કરે છે, જ્યારે ફોરવર્ડિંગ પગલું હોસ્ટનેઝ ફરી લખી શકે છે?

રચનાને એક ફકરામાં સમજાવી શકાય એટલી નાની રાખો: જરૂરી ઘટનાઓ વહન કરતું સૌથી નાનું સમર્થિત પરિવહન, સાથે તે જે ગેરંટી આપતું નથી તેનું સ્પષ્ટ નિવેદન। જવાબને બે પગલાંની જરૂર હોય તો runbook માં કહો અને દરેક પગલાને માલિક આપો।