NewRelicでCSPM (Cloud Security Posture Management) - Qiita
AWSだけで実装する場合の問題点 AWSにもSecurityHubを使うことで発見的統制や予防的統制を管理することができますが、大量アラートが発生することも多いことが実情です。また、セキュリティイベントという性質上、かんたんに無視できず運用負荷になりがちです。 【問題点】 アラートチューニングに適していない ログ検索のプラットフォームとの連動に作り込みが必要で、日々のセキュリティイベントの件数の分析などが難しく、件数を減らすためのチューニングが困難です。 独自ルールの設定ができない AWSのベストプラクティスに則ったルールが適用されますが、社内のルールなど独自ルールを導入しずらく、統制の観点で要求レベルを満たさない場合があります。 アカウントを横断して管理しにくい このような監査基盤はCCoEなど全社横断の組織が管理することが多く、マルチアカウントの管理が必要となります。 NewRelic
New Relic のサーバーレスモニタリング for AWS Lambdaを手動で導入してみた | DevelopersIO
ライセンス・キーは本来管理を厳重にする必要があるため、公式では AWS Secrets Manager を利用する手順となっていますが、ここでは動作検証が目的なのでそのまま環境変数にいれてます。 なお、アカウント ID の調べ方やキーの発行方法については、不明な方はここらあたりが参考になると思いますのでご参照ください！ アカウントID | New Relicのドキュメント New Relic ライセンスキー | New Relicのドキュメント 被験者 観測する対象の Lambda 関数ですが、適当なものが手元になかったので、Blueprint から作った素のhello-world-pythonを使いました（観測してもあまり面白くなさそうと思いつつ）。 Runtime : Python 3.7 Handler : lambda_function.lambda_handler Runtime
Lambda Extensionに対応した、New Relic サーバーレスモニタリングを試してみた | DevelopersIO
こんにちは、New Relicの田中です。 先日AWSから発表されたLambda Extensions (プレビュー版)、早速こちらの記事で解説されています。 【新機能】Lambda Extensions(プレビュー版)がリリースされました！ New Relicのサーバーレスモニタリング for Lambdaも対応済みですので、早速試してみました。 なにがうれしいのか？ ユーザー目線では、セットアップが楽になる点が挙げられます。内部の仕組みを考えると、いままでラムダ関数本体の中で設定していた可観測性のための仕組みを、AWSが提供するラムダ関数本体と切り離した枠組み（Runtime）の中で提供できることになります。 (図はNew Relicのドキュメントより引用） Runtimeをライフサイクルの視点でとらえると、関数本体が実行される前にRuntimeの初期化が完了しており、関数本体が終了し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
