Topic 1 Question 170
One of your primary business objectives is being able to trust the data stored in your application. You want to log all changes to the application data. How can you design your logging system to verify authenticity of your logs?
Write the log concurrently in the cloud and on premises
Use a SQL database and limit who can modify the log table
Digitally sign each timestamp and log entry and store the signature
Create a JSON dump of each log entry and store it in Google Cloud Storage
ユーザの投票
コメント(17)
Correct answer is C (verified from Question Bank in Whizlabs.com)
Feedback C (Correct answer) - Digitally sign each timestamp and log entry and store the signature. Answer A, B, and D don’t have any added value to verify the authenticity of your logs. Besides, Logs are mostly suitable for exporting to Cloud storage, BigQuery, and PubSub. SQL database is not the best way to be exported to nor store log data. Simplified Explanation To verify the authenticity of your logs if they are tampered with or forged, you can use a certain algorithm to generate digest by hashing each timestamp or log entry and then digitally sign the digest with a private key to generate a signature. Anybody with your public key can verify that signature to confirm that it was made with your private key and they can tell if the timestamp or log entry was modified. You can put the signature files into a folder separate from the log files. This separation enables you to enforce granular security policies.
👍 26get2dd2021/02/19C is correct and common practice
👍 23JoeShmoe2019/11/14C – Digitally sign each timestamp and log entry and store the signature. This is fun Q where all options are technically correct. But, the point is to find most efficient. Since, Q asks about verification of log entry - then you don't need to dub it. Using of much shorter timestamp-hash pair will address the request. So, when reading log from original source, you also read hash for this timestamp and then verify the entry's body. BTW, this is one of general purpose questions, which is not directly related to GCP. Just checks your attentiveness A - is about duplication, can work, but redundant; B / D - both have similar design, but don’t allow verification of entry. No cross-checking of entry. E.g. person having access to log can change it in one place. C - storing log in one place, and hash-code in another. So, even if "trusted" person has modified original log, then it will break correspondence with hash code in other storage. That storage should be available only for authentication program (via service account).
👍 5MaxNRG2021/10/23
シャッフルモード