Загрузка...

【CISA試験対策L3.4】アジャイル開発とDevOpsの監査|速い開発でも統制は消えない

情報システム監査の世界基準資格、CISA(公認情報システム監査人)への挑戦!🐸✨

CISA試験対策講座、レクチャー3.4へようこそ!案内役のSecurity Frogです。

今回は、ドメイン3「情報システムの取得・開発・導入」の第4回として、
「アジャイル開発とDevOpsの監査」を学びます。

前回のL3.3では、SDLCを通じて、企画から廃棄までの開発ライフサイクルにおける統制ポイントを整理しました。

今回はそこから一歩進んで、
ウォーターフォール的なフェーズ管理だけではなく、
アジャイル開発やDevOpsのような「速い開発」の中で、
監査人がどのように統制、証跡、承認、職務分離を確認するのかを見ていきます。

冒頭では、パスワード、トークン、秘密鍵、APIキーなど、
似ているようで違う「秘密情報」の話からスタートします。

Security Frogもこの業界に入ったころは、
「パスワードを守れば大丈夫」と思っていました。

しかし実務では、CI/CDパイプライン、IaC、環境変数、リポジトリなどに、
認証情報や秘密情報が入り込みます。

ここを理解しないままDevOpsを監査すると、
「自動化されているから安心」という危ない誤解に陥ります。

今回の動画で学べることは、以下の通りです。

・アジャイル開発とは何か
・スクラム、スプリント、プロダクトバックログの基本
・スプリントレビュー、レトロスペクティブの監査上の見方
・DevOpsとは何か
・CI/CDパイプラインの基本
・自動テスト、自動デプロイ、IaC、監視の監査ポイント
・アジャイルでも証跡が必要な理由
・DevOpsでも職務分離が不要にならない理由
・変更管理、承認、ログ、ロールバック手順の確認ポイント
・CISA試験で問われる「監査人の判断軸」

実務の泥沼としては、こんな場面を扱います。

JiraやBacklogにはチケットが山ほどある。
でも、どれが正式な要件で、誰が承認し、どのリスクを受け入れたのか分からない。

CI/CDで本番反映は自動化されている。
でも、障害が起きたあとに、誰が承認したのか、どのテストを通ったのか、どう戻すのか説明できない。

これは「速い開発」ではなく、「速い事故」です。

CISA試験では、アジャイルやDevOpsを否定する選択肢も、
無条件に受け入れる選択肢も危険です。

監査人は、開発手法を選ぶ人ではありません。
監査人は、開発プロセスの中で、
リスクに応じた統制、証跡、承認、責任分界、独立性が機能しているかを評価する人です。

今回のキーワードは、
「スピードと統制の両立」です。

速いから仕方ない、ではありません。
速くても統制されているか。

この監査人の眼鏡を、今回も一緒に身につけていきましょう。

次回は、L3.5「要件定義とコントロールの組み込み」を扱う予定です。
システムを作ってから統制を考えるのではなく、要件定義の段階でどのようにコントロールを組み込むのかを見ていきます。

【講師プロフィール:Security Frog】
官公庁のネットワーク屋からキャリアをスタートし、現在は民間上場企業のセキュリティ担当として、リアルなセキュリティ運用に従事。将来のCISOを目指して奮闘中。現在、AIIT(産業技術大学院大学)にて学習中。
保有資格:CISSP、PMP、情報処理安全確保支援士、CISA(学習中)

【免責事項】
本動画の内容は個人の見解であり、所属する組織やISACAの公式見解を代表するものではありません。学習の際は最新の公式資料も併せてご確認ください。

Видео 【CISA試験対策L3.4】アジャイル開発とDevOpsの監査|速い開発でも統制は消えない канала Security Frog
Яндекс.Метрика
Все заметки Новая заметка Страницу в заметки
Страницу в закладки Мои закладки
На информационно-развлекательном портале SALDA.WS применяются cookie-файлы. Нажимая кнопку Принять, вы подтверждаете свое согласие на их использование.
О CookiesНапомнить позжеПринять