Open2
SoftwareDesign_202308
dehio3アジャイル開発の課題に立ち向かう
アジャイルの原則を再確認
- 数あるソフトウェア開発手法の1つ
- ソフトゥエア開発の不確実性に向き合い、より良い開発を目指すための開発手法
- アジャイル開発ソフトウェア宣言
- アジャイル宣言の背後にある原則
- 「ストリームプログラミング（XP）」「スクラム」がアジャイル開発手法として多く採用されている
- XP
- 1990年代に考案された開発手法
- 「価値」「原則」「プラクティス」という概念
- 価値：ソフトウェア開発を成功させるためにチームが重視すべき価値観
- 原則：チームが取り組むプラクティスがXPの価値に調和したものかどうかの指針
- プラクティス：具体的な方法や手法
- チームがプラクティスを実践することによって、原則が遵守され価値が実現する
- 「チームにとって大切なこと、集中すべきこと」としての「開発を導く５つの価値」
- コミュニケーション
- シンプリティ
- 利用者が理解できるものか
- 伝わりやすく表現されているか
- 重複がなく、うまく分割されているか
- 必要最小限のものとなっっているか
- フィードバック
- 勇気
- リスペクト
- 代表的なプラクティス
- チーム全体（Whole Team）／多様性の原則
- 機能横断的なチーム（クロスファンクショナルチーム）を作る
- ペアプログラミング／冗長性の原則
- 継続的インテグレーション／継続的な流れで価値を生み出す原則
- チーム全体（Whole Team）／多様性の原則
スクラムを「回す」ための実践ポイント
- 「スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという三つの明確な責任を定義する」
- スクラムをより効果的に実践するためのスクラムの三本柱と、５つの価値基準
- スクラムの三本柱
- 透明性
- スクラムにおける重要な意思決定は、三つの正式な成果物を認知する状態に基づく
- プロダクトバックログ
- スプリントバックログ
- インクリメント
- スクラムにおける重要な意思決定は、三つの正式な成果物を認知する状態に基づく
- 検査
- 作成物と進捗状況は、頻繁かつ熱心に検査されなければならない
- スプリントレビュー
- デイリースクラム
- 作成物と進捗状況は、頻繁かつ熱心に検査されなければならない
- 適応
- 透明性により仕事のあらゆる物事を検査できるようになることで、明らかになった課題の解決や、やり方の改善を行う。
- スプリントレトロスペクティブ
- 透明性により仕事のあらゆる物事を検査できるようになることで、明らかになった課題の解決や、やり方の改善を行う。
- 透明性
- ５つの価値基準
- 確約
- 集中
- 公開
- 尊敬
- 勇気
アジャイルな設計・開発
- 「包括的なドキュメントよりも動くソフトウェアを」=「ドキュメントを書かない」ではない。
- 「必要なときに、ひつようなだけ」設計する
- 設計はプランニング時に行う
- ドキュメントは成果物ではなく、チーム内の認識を合わせるためのもの
技術的負債
- 技術的負債の四象限
- https://bliki-ja.github.io/TechnicalDebtQuadrant/
- 無鉄砲かつ不注意な負債
- 設計時に十分に議論されていない
- チームメンバーに十分な知識がない
- 気づかれずに後になって深刻な問題として表面化する
- 無鉄砲かつ意図的な負債
- 時間や実装コストの問題で負債と認識しながらリリースされたもの
- リリースして動いてしまうと興味を失い残り続ける
- 慎重かつ意図的な負債
- 他の選択肢を考慮した上で、あとに深刻な問題にはならないと判断したもの
- 「踏み倒す」ことができる負債
- 慎重かつ不注意な負債
- システムの成長に従って浮き彫りになる問題
- 適宜対応
アジャイルをスケールさえる必要性とその課題
- スクラムガイドの開発チーム適正規模は9名以下
- 1つのプロダクトを複数チームで開発する場合の成功要因
- 分担と結合：バックログを実現するために最適なチーム編成にする
- チーム編成単位
- プロセス単位
- 特定のプロセスでサイロ化するので避けるべき
- コンポーネント単位
- システムの構成要素単位
- 1つのユーザーストーリーで複数のシステムを利用する場合は協力が必要
- チームがプロダクトのゴールや目的感を見失いがちになる
- ユーザーストーリー単位
- バックログアイテムまたはユーザーストーリー単位
- １チームが一貫してテスツ剃るので提供機能に対する責務が明確になる
- ソースの衝突は生まれやすい
- システム範囲が広がるのでメンバーが一定の技術スキルが必要
- プロセス単位
- チーム編成単位
- 調整：チーム間で効率的にコミュニケーションを取る
- 共通化：適度に共通化してムダやムラを減らしつつ高いアジリティを維持する
- ルール
- アーキテクチャ
- アーキテクチャは決定事項ではなく、ガイドラインとして扱う
- 特定のサービス、製品に依存した設計はしない
- その時点で必要のない機能を設計に含めない
- 密結合な設計をできる限り避けること
- CI/CDパイプライン
- 結合と開発で使うパイプラインを分ける
- 開発で使うパイプラインは各チームがメンテナンスできる程度の機能にとどめる
- コミットメッセージやブランチによって走るジョブを選択できるようにすること
- 自動化を目的とせず、アジリティ向上をもう的にパイプラインを設計すること
- 大規模アジャイルフレームワーク
- Nexus
- LeSS
- Scram@Scale
- SAFe
- 分担と結合：バックログを実現するために最適なチーム編成にする
dehio3マルウェア対策とエンドポイントセキュリティ
Emotet
- 世界で最も危険なマルウェア
- アクセスされるたびにコードが少しずつ変化するポリモーフィック型なので検知が難しい
- 検知／除去から逃れるために自動的に構造を変化させる
- スキャンされることを察知して、動作を停止する場合もある
- Emotet自体に不正なコードはほとんどないので、コードを分析するスキャンでも検知が難しい
- ローダーもしくはダウンローダーと呼ばれるツールで、本体に不正な機能がほとんどない
- 初期侵入時は不正なコードを抱える必要がなく、後から悪いモジュールをダウンロードしていく
- モジュールも難読化などのスキャンから身を隠す工夫がされている
- 主にメール添付のマクロを有効化すると、PowerShellが起動してEmotetがダウンロードされる
- メールに添付されているのはEmotetそのものではなく、Emotetを導入させるためのVBAコードのマクロ
- パスワード付きZIPファイル（PPAP）はスキャンできないのでリスクを高める行為でやめるべき
C&Cサーバとボットネット
- C&CはCommand & Controlの略
- ボットに感染した端末に指示を出す役割
- 有名な攻撃としては、感染端末に特定のサーバに一斉アクセスさせるDDos攻撃
- C&Cが停止させられても攻撃が継続できるよう複数用意されている
- ボットに感染した端末とC&Cサーバ群の構成ボットネットと言う
- Emotetはボットネットを構築するマルウェア
- 2021.1.27に国際的な連携のもとC&Cサーバの一斉押収が実行されたが、同年7月頃には活動が再開された
MaaSとしてのEmotet
- Emotet開発組織もEmotetと呼ばれている
- 2014年までのEmotet組織は誕生
- 2017年から自分たちで攻撃するスタイルから、構築したボットネットのアクセス権限をクラウドサービスとして提供を開始
- MaaS（Malware as a Service）
- ランサムウェア攻撃の場合はRaaS（Ransomware as a Service）
- 身代金の成功報酬として3割をプラットフォームに支払う仕組み
ランサムウェア攻撃
- Emotetと同等以上に凶悪なサーバー攻撃がランサムウェア攻撃
- ボットネットの延長にあるリスク
- データを盗み出してから端末データを暗号化して身代金を要求する